Beispielhafte Implementierung: PEP, PDP und Fachdienst
Die Komponentenübersicht im ZETA-Produkthandbuch benennt NGINX HTTP Proxy im PEP und Keycloak, PostgreSQL, Open Policy Agent und Infinispan im PDP. Provisioning Processor übernimmt signierte Vertrauensanker. Einzelne Bausteine wie das Telemetry Gateway, Ingress, Service Mesh, Benachrichtigungsdienst und OPA-Simulation sind im Handbuch als optionale oder ersetzbare Komponenten beschrieben. Eine konkrete gematik-Konformität oder ITL-Installation folgt daraus nicht.
Der Guard prüft Infrastruktur-Token, DPoP und je nach Dienst PoPP bzw. ASL. Fachliche Berechtigungen bleiben zusätzlich Sache des jeweiligen Resource Servers und dessen eigener Produktvorgaben. Ein erfolgreiches Policy-Beispiel darf nicht mit einem produktiven Zugang gleichgesetzt werden.
Draft: sechs Etappen der Client-Interaktion
Die API-Dokumentation vom 01.09.2026 trägt ausdrücklich den Status ZETA API v2.0.0-draft: Discovery der .well-known-Metadaten, clientseitige Schlüssel, Dynamic Client Registration, plattformabhängige Attestation, OIDC-Anmeldung über PAR/PKCE, Nonce- und DPoP-gebundenen Tokenbezug sowie den Zugriff auf einen geschützten Resource Server.
Die eigene SDK-Anleitung bezeichnet den mobilen OIDC-Ablauf als Vorschau und die serverseitige mobile Attestation im beschriebenen Implementierungsstand als gemockt. E-Mail-/OTP-Bindung und Systembrowser-Callbacks sind Preview-Szenarien; eine reale iOS-/Android-Anbindung kann aus einem Website-Walkthrough nicht abgeleitet werden.
DiPag-Beispielpolicy: Umfang genau begrenzt
Die Datei pip-pap/dipag-policy/policies/zeta/authz.rego entscheidet anhand professionOID, zugewiesener Rolle und erlaubter Scopes. Die Beispieldaten in professions/data.json enthalten OID-zu-Rolle- und Rolle-zu-Scope-Tabellen. Fehlt die erlaubte Berufs-OID oder der Scope, gibt die Beispielregel Gründe für allow=false zurück.
Die Datei enthält zwar Helper für client_product_is_allowed und audience_is_allowed, diese sind jedoch nicht Teil der gezeigten Hauptentscheidung. Deshalb simuliert das Website-Beispiel ausdrücklich nur Berufs-/Scope-Bedingungen. Tokenprüfung, Fachoperationen und reale Systemberechtigungen werden nicht ausgeführt.
2.0.1_CC wird erwähnt, ist aber nicht enthalten
Die Keycloak-Architekturvorschläge vom 21.09.2026 referenzieren Abschnitte der ZETA 2.0.1_CC und diskutieren eine alternative Client-Management-Umsetzung. Sie sind redaktionelle und technische Vorschläge, keine vollständige Normausgabe und keine offiziell bestätigte Korrektur des G-App-PTV.
Das Repository-Snapshot ist eine vom Nutzer bereitgestellte main-Kopie ohne hier unabhängig bestätigten Tag/Commit-Bezug. Seine Provenienz wird durch die SHA-256 des gesamten ZIP und ausgewählter Dateien gesichert. Offizielle produktbezogene PTV/ATV und freigegebene Spezifikationen bleiben eigene Quellen.