Verbindliche Referenzkette des ZETA Guard
Der freigegebene Verzeichnissteckbrief ZETA Guard 1.3.0-0, Dokument 1.0.2 vom 30.06.2026, bindet in Tabelle 1 gemSpec_ZETA 1.3.2 und gemSpec_Krypt 2.47.0. Seine Prüftabellen wählen konkrete Anforderungs-IDs aus; ein Verweis auf die Spezifikation macht nicht automatisch jeden Absatz zur ausgewählten Guard-Pflicht. Die öffentliche Zuordnung nennt deshalb ID, Quellenversion, verantwortliche Komponente und die vorhandenen Prüfzuordnungen. Die G-App-Basis besitzt eine eigene Entwurfsreferenz auf ZETA 2.0.1_CC und Krypt 2.49.1; diese Referenzkette bleibt getrennt.
Discovery, Zertifikate und Registrierung je Guard
Der Client prüft aktiv verwendete Zertifikate einschließlich Hostname, Gültigkeit, Vertrauenskette und Widerruf nach A_25340-01; von einer ungültigen Prüfung abhängige Abläufe werden abgelehnt. Well-known-Abfragen verwenden ETag und If-None-Match. Ohne Cache-Control werden Well-known und JWKS alle 24 Stunden neu geladen; ein 404 beim Aufbau der Ressourcenkommunikation löst erneute Discovery aus. Der Guard veröffentlicht genau einen logischen Authorization Server. Die Registrierung erfolgt pro Guard; client-id sowie Registrierungs- und Konfigurationsdaten bleiben diesem Guard zugeordnet. Eine fachliche App-Kachel ist keine eigene Registrierungsinstanz.
PEP: Token-Bindung und gezieltes Step-up
Der PEP HTTP Proxy prüft Signatur, zeitliche Gültigkeit, Audience und Scope des Access Tokens sowie die DPoP-Bindung; die DPoP-Prüfung folgt RFC 9449. Ein ungültiges Access Token führt gemäß A_25668 zu HTTP 401. A_28525-01 verlangt ein Step-up-Signal mit HTTP 401, wenn bei einer existierenden, unterstützten URL der benötigte Scope fehlt oder die Audience nicht passt. Daraus folgt keine Regel, nach jedem beliebigen 401 pauschal eine neue MFA-Abfrage zu starten. Die fachliche Anwendung wertet den konkreten Autorisierungskontext aus und erhält keinen Zugriff allein durch ein sichtbares Login-Signal.
ASL: innere und äußere Zielbindung
A_26681-01 bindet die Verwendung des ZETA/ASL-Kanals an zeta_asl_use: required oder required_passthrough. Der innere Request enthält Access Token und DPoP Token für den Resource-Server-Endpunkt. Bei required_passthrough enthält zusätzlich der äußere Request ein passendes Token-Paar für den ASL-Endpunkt. Terminiert ASL am HTTP Proxy, prüft dieser das innere Token-Paar. Bei Passthrough prüft er das äußere Paar und leitet an den terminierenden Resource Server weiter. Die Wahl des Dienstes und seiner Produktspezifikation bestimmt diese Grenze; die allgemein optionale Guard-Konfiguration hebt eine dienstspezifische ASL-Pflicht nicht auf.
PDP, Fachautorisierung und Token-Lebenszyklus
Vor einem neuen Token-Set fragt der Authorization Server die Policy Engine. Eine verweigerte Policy-Entscheidung wird mit HTTP 403 umgesetzt; Token-Claims müssen zur Entscheidung passen. Access und Refresh Token sind über DPoP an die registrierte Client-Instanz gebunden. Refresh Token werden nur einmal eingetauscht und rotiert; der Client bewahrt Sitzungstoken und DPoP-Schlüssel geschützt auf. Ein anwendungsspezifisches Authorization Backend kann über die definierte Plug-in-Schnittstelle einbezogen werden. Clientverwaltung, manuelle De-Registrierung und Einsicht in das Registrierungs-Zugriffsprotokoll bleiben eigene Funktionen. Diese ZETA-Funktionen ersetzen weder ePA-Befugnisse noch die Fachregeln einer DiPag- oder TI-Flow-Operation.
Stufe 1 ist kein allgemeiner mobiler Ablauf
A_28827 und A_28803 betreffen ausdrücklich Stufe 1: Die anfragende IP-Adresse wird im Access Token hinterlegt und bei Client-Requests verglichen. Ein negatives Ergebnis sperrt Access und Refresh Token und bricht die fachliche Operation ab. Die Spezifikation ordnet diese vereinfachte Impossible-Travel-Prüfung der LEI-Rolle mit stationärem Endgerät zu. Die mobile HCSA-Illustration übernimmt daraus keine universelle IP-Bindung. Mobile Aussagen aus 2.0.0_CC behalten ihren Entwurfsstatus; die im G-App-PTV referenzierte Fassung 2.0.1_CC bleibt bis zum Vorliegen der exakten Quelle ungeprüft.
G-App: genaue Anforderungsauswahl bei offener Quellenversion
Der G-App-PTV enthält 57 unterschiedliche ZETA-Anforderungs-IDs mit 66 Prüfzuordnungen. Er nennt ausdrücklich 2.0.1_CC. Im geprüften Kontextentwurf 2.0.0_CC stehen A_25783-01 und A_27379-02, während der PTV A_25783-02 und A_27379-03 auswählt. Die 55 dort gefundenen identischen IDs belegen keine Textgleichheit zur fehlenden Ausgabe. Die SDK-Ausnahme in § 3.2.1 betrifft nur bereits durch Zeta-SDK-Funktionalität abgedeckte Anforderungen der Tabelle 7; übrige Prüfungen und Herstellerpflichten bleiben eigenständig. A_25735-01 steht sowohl in der allgemeinen UX-Tabelle 5 als auch in Tabelle 10 der Option PushNotification. Beide Zuordnungen bleiben erhalten. Der Katalog macht den PTV-Bezug prüfbar; der volle Inhalt von 2.0.1_CC bleibt offen.
Mobiler Ablauf im Entwurf ZETA 2.0.0_CC
Der öffentlich vorliegende Entwurf beschreibt die mobile Registrierung mit lokal erzeugtem Schlüssel, Attestierungsnachweis und beim Erstkontakt E-Mail-OTP-Bestätigung. Der schnelle Registrierungsweg setzt einen bereits gültigen ZETA-Attestierungstoken und weitere Schlüsselprüfungen voraus. Android-Hardwareattestierung und Apple App Attest werden plattformspezifisch behandelt; der Software-Fallback besitzt keine Hardware-Vertrauensbindung und erhält eine niedrigere Vertrauensbewertung. Für OIDC beschreibt der Entwurf Authorization Code, PAR und PKCE sowie DPoP-gebundene Access-Token. Der Fach-Client bestimmt den fachlichen Aufruf und den IDP-Kontext; der ZETA Client verwaltet Registrierung, Schlüssel und Authentifizierungsablauf. Diese Aussagen beziehen sich ausschließlich auf 2.0.0_CC. Der illustrative Zwölf-Screen-Flow bleibt ein ITL-Beispiel ohne Implementierungsnachweis.