Example implementation: PEP, PDP and service
The ZETA Guard component overview names NGINX HTTP Proxy in the PEP and Keycloak, PostgreSQL, Open Policy Agent and Infinispan in the PDP. The provisioning processor obtains signed trust anchors. Telemetry gateway, ingress, service mesh, notification service and OPA simulation are described as optional or replaceable in this manual. This is not evidence of gematik conformance or an ITL deployment.
The Guard checks infrastructure tokens, DPoP and, where applicable, PoPP and ASL. Business entitlements remain the duty of the relevant resource server and its product-specific requirements. Passing an example policy cannot be equated with production access.
Draft: six stages of client interaction
The API documentation dated 1 September 2026 is explicitly marked ZETA API v2.0.0-draft: discovering .well-known metadata, local keys, Dynamic Client Registration, platform-dependent attestation, OIDC sign-in through PAR/PKCE, nonce- and DPoP-bound token requests, and access to a protected resource server.
The mobile SDK guide calls the mobile OIDC flow a preview and says mobile server-side attestation is mocked in the documented implementation. E-mail/OTP binding and system-browser callbacks are preview scenarios; a live iOS/Android integration cannot be inferred from a website walkthrough.
DiPag example policy: exact scope
The pip-pap/dipag-policy/policies/zeta/authz.rego example decides using professionOID, assigned role and allowed scopes. The professions/data.json file contains the OID-to-role and role-to-scope mapping. Missing an allowed profession or scope yields denial reasons in the example.
The file also defines client_product_is_allowed and audience_is_allowed helper rules, but they are not part of the primary decision. Therefore the site simulates profession/scope checks only. No production token verification, business operation or actual system authorization is performed.
2.0.1_CC is referenced, not provided
The Keycloak architecture proposals dated 21 September 2026 reference sections of ZETA 2.0.1_CC and propose alternative client-management implementation details. These are technical proposals, not the complete normative edition or an official correction to the G-App PTV.
The supplied repository is a main-branch snapshot without an independently verified tag/commit here. The full ZIP and selected files are recorded by SHA-256. Official product PTV/ATV and released specifications remain distinct sources.