Die mobile Anwendung für Versicherte.

Der FdV-Produkttypsteckbrief 3.1.3-3, Dokument 1.0.0, bindet die hier betrachtete Dokumenten- und Zugriffsarchitektur an gemSpec_ePA_FdV 2.8.0, Aktensystem 1.8.2 und IDP Frontend 2.0.0. Dazu gehören Basic IG 1.3.2, MHD IG 1.1.3 und Medication IG 1.3.5. Das FdV ist das Versicherten-Frontend; das Aktensystem setzt Aktenhaltung und serverseitige Zugriffsprüfung um. Produktanforderungen an das Aktensystem und Anforderungen an dessen Anbieter stehen in eigenen PTV-/ATV-Steckbriefen 3.1.3-3. Ein mobiles UI-Konzept erfüllt diese drei Nachweisscopes nicht allein. Die Schnittstellenreferenzen ePA-Basic und ePA-XDS-Document sind auf ePA-3.1.3 und die dazu ermittelten unveränderlichen Commits festgelegt.

• ePA FdV PTV 3.1.3-3, V1.0.0 · Tabellen / Tables 1–2, S. / pp. 7–8 ↗
• ePA Aktensystem PTV 3.1.3-3, V1.0.0 ↗
• ePA Aktensystem ATV 3.1.3-3, V1.0.0 ↗

Das FdV baut einen VAU-Kanal zum Aktensystem auf und prüft dabei dessen VAU-Zertifikat. sendAuthorizationRequestFdV leitet die Authentifizierung über GesundheitsID, sektoralen IDP und Authenticator ein; sendAuthCodeFdV übergibt den erhaltenen Autorisierungscode an das Aktensystem. Die authentifizierte userSession ist vom HealthRecordContext einer konkreten Akte zu unterscheiden. Eine Aktenanfrage benennt die Akte über x-insurantid und setzt die passende Befugnis sowie die weiteren Zugriffsprüfungen voraus. So können Inhaber und berechtigte Vertretung auf unterschiedliche Akten zugreifen. Ein generisches ZETA-Allow oder ein TI-M Client ePA Login ersetzt diesen ePA-FdV-Vertrag nicht.

• gemSpec_ePA_FdV 2.8.0 · §§ 6.1.2, 6.2.3.1 · A_24557 / A_24830 / A_24831 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · § 3.7 ↗
• I_Authorization_Service 1.9.1 · sendAuthorizationRequestFdV / sendAuthCodeFdV · commit 3186ad27 ↗

logoutFdV beendet die userSession, löscht die zugehörigen temporären Sitzungsdaten und schließt ihre HealthRecordContexts. Für weiteren Zugriff sind eine neue Anmeldung und ein neu ausgehandelter VAU-Kanal erforderlich. Das FdV beendet die Sitzung spätestens 20 Minuten nach der letzten Nutzer-Aktivität; auch das Aktensystem besitzt eine Inaktivitätsregel. deleteDevice entfernt dagegen eine Gerätefreigabe. Laut Geräte-API bleibt eine bereits aktive userSession davon unberührt. Ein Produkt muss deshalb Abmelden und Geräteverwaltung als unterschiedliche Aktionen behandeln. Die lokale HCSA-Demo hält keine echte ePA-Sitzung und führt keine dieser Operationen aus.

• gemSpec_ePA_FdV 2.8.0 · A_15295-02 / A_15296-02 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · A_25006 ↗
• I_Authorization_Service 1.9.1 · GET /epa/authz/v1/logoutFdV · operationId logoutFdV ↗
• I_Device_Management_Insurant 1.10.1 · operationId deleteDevice · aktive Sitzung / active session ↗

Am Heimat-Aktensystem weist das FdV ein registriertes und bestätigtes Gerät mit x-device-identifier und x-device-token nach. Bei einem anderen Aktensystem dient eine Geräteattestierung des Heimat-Aktensystems als Nachweis. Fehlt die bestätigte Registrierung, bleibt die authentifizierte Sitzung auf die Geräteverwaltung beschränkt. registerDevice und confirmPendingDevice bilden Registrierung und Bestätigung ab; getDeviceAttestation setzt ein bestätigtes Gerät voraus. Der besondere Modus x-authorize-representative dient der Einrichtung einer Vertretung und beschränkt den Zugriff auf die Befugnisverwaltung. Er öffnet keine allgemeine Dokumentensitzung. GesundheitsID-Anmeldung, Gerätebestätigung und Aktenbefugnis haben somit jeweils einen eigenen Zweck.

• I_Authorization_Service 1.9.1 · sendAuthCodeFdV · Geräteprüfung / device verification ↗
• I_Device_Management_Insurant 1.10.1 · registerDevice / confirmPendingDevice / getDeviceAttestation ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · A_25291 / A_26157 ↗

Entitlement Management verwaltet die Befugnis eines Akteurs auf eine bestimmte Akte. Der Inhaber hat eine statische Befugnis; eine Vertretung benötigt eine ausdrückliche Befugnis. setEntitlement verarbeitet einen signierten Befugnisnachweis, deleteEntitlement entzieht eine widerrufbare Befugnis. Consent Decision Management setzt dagegen den Widerspruch gegen definierte Funktionen um: permit bedeutet kein Widerspruch, deny einen Widerspruch mit funktionsabhängigen Folgen. Der allgemeine Widerspruch gegen die ePA selbst liegt außerhalb dieses Dienstes. Constraint Management steuert das Verbergen zulässiger Dokumente, Ordner oder Kategorien über GeneralDenyPolicies; emp und technical können hier nicht verborgen werden. Die serverseitige LegalPolicy und Rollenprüfung gelten zusätzlich. Favoriten in der HCSA-Demo sind lediglich lokale Lesezeichen und ändern keine dieser Berechtigungen.

• gemSpec_ePA_FdV 2.8.0 · §§ 6.2.5–6.2.7 · A_24399-01 / A_26280 ↗
• I_Entitlement_Management 1.8.0 · setEntitlement / deleteEntitlement ↗
• I_Consent_Decision_Management 1.7.1 · updateConsentDecision ↗
• I_Constraint_Management_Insurant 1.6.1 · setDenyPolicyAssignment · commit c88635c4 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · §§ 3.8–3.11 · A_24548 ↗

XDS verwendet SOAP/WSDL, etwa DocumentRegistry_RegistryStoredQuery für Metadatensuche und DocumentRepository_RetrieveDocumentSet für den Abruf. Der zusätzliche MHD-Consumer des FdV nutzt DocumentReference-Suche und -read: Find Document References (ITI-67) verbindet Metadaten mit der Volltextsuche über _content. Jede MHD-Suche belegt mindestens patient.identifier und status; der Pfad lautet /epa/mhd/api/v1/fhir/DocumentReference. Retrieve Document (ITI-68) ruft den Inhalt über DocumentReference.content.attachment.url ab. Ein nicht vorhandenes und ein vor dem Anfragenden verborgenes Dokument liefern dabei beide 404. Basic IG 1.3.2 beschreibt unter anderem Patient und AuditEvent; Medication IG 1.3.5 beschreibt eML/eMP. Diese Verträge sind getrennt. Der HCSA-Filter durchsucht lokal Namen und Datum synthetischer Dokumente und implementiert keine MHD-Volltextsuche.

• gemSpec_ePA_FdV 2.8.0 · §§ 6.2.8.1–6.2.8.4 · A_24706 / A_24708 ↗
• XDSDocumentService.wsdl · ePA-3.1.3 · commit c88635c4 ↗
• MHD IG 1.1.3 · Find Document References ↗
• MHD IG 1.1.3 · Retrieve Document ↗
• Basic IG 1.3.2 · Patient / AuditEvent ↗

Der FdV-PTV 3.1.3-3 nennt TI Common 1.3.0. Die tatsächlich geprüften Pakete de.gematik.epa 1.3.2 und de.gematik.epa.mhd 1.1.3 deklarieren dagegen de.gematik.ti 1.3.1 als Abhängigkeit. Die beiden Common-Versionen sind deshalb getrennt dokumentiert. Ein konkreter Unterschied liegt im Profil TI Organization: 1.3.1 setzt mustSupport=true auf Organization.extension; in 1.3.0 fehlt diese Kennzeichnung an diesem Element. Das ist relevant für die Auswertung von Profilanforderungen und zugehörige Tests, beweist für sich allein aber keine Inkompatibilität im Datenaustausch. Eine offizielle Auflösung des Versionsunterschieds ist im geprüften Material nicht enthalten. Weder eine automatische Ersetzung des PTV-Pins noch eine pauschale Konformitätsaussage wird daraus abgeleitet.

• ePA FdV PTV 3.1.3-3 · Tabelle / Table 1 · TI Common 1.3.0 ↗
• de.gematik.epa 1.3.2 · package.json dependencies ↗
• de.gematik.epa.mhd 1.1.3 · package.json dependencies ↗
• TI Common 1.3.0 · TI Organization ↗
• TI Common 1.3.1 · TI Organization ↗

Versicherte kommunizieren über TI-M Client ePA und TI-M Fachdienst ePA. Fachanwender und der zentrale Contact-Center-Host nutzen die Pro-Produktrollen. TI-M ePA ergänzt die Basis um Authentisierung am sektoralen KTR-IDP mit OIDC/PAR und die Verzeichnissuche /fdv/search. Client und Fachdienst verhindern die Raumeinstellungen public/knock für Join Rules, world_readable für History Visibility, public für das Raumverzeichnis und inaktive Verschlüsselung; unzulässige Raumänderungen lehnt der Fachdienst mit HTTP 400 und M_INVALID_ROOM_STATE ab. Versicherte erhalten keine Administration fremder Nutzerkonten; Einladungen zwischen zwei Versicherten werden durch den TI-M-ePA-Proxy im Client-Server-Pfad abgelehnt. Der Zugriff auf die elektronische Patientenakte besitzt einen eigenen ePA-FdV-/Aktensystemvertrag.

• gemSpec_TI-M_ePA 1.3.1 · A_25488 / A_25696 / A_25681-01 / A_26383-01 / A_26015-02 / A_25996-02 / A_25705 ↗
• gemSpec_TI-M_Pro 1.2.0 · § 3.3.4 Contact Center ↗

TI-M ePA Clients müssen de.gematik.questionnaire.generic v1 und de.gematik.questionnaire.consent v1 auf Empfängerseite unterstützen: Capabilities unmittelbar nach Login veröffentlichen, empfangene Fragebögen einschließlich Vorbelegungen ausfüllbar darstellen, finale Antworten als de.gematik.fhir-Event zurücksenden und beantwortete Fragebögen später wieder anzeigen. Die Pflicht betrifft den TI-M Client ePA. Sie beschreibt keinen bereits nachgewiesenen MEMM-Formularumfang und gewährt keinen Zugriff auf die elektronische Patientenakte.

• gemSpec_TI-M_ePA 1.3.1 · A_28528 ↗

Der App-Entwurf setzt sich aus dem G-App-Basissteckbrief und den Steckbriefen der gewählten Fachmodule zusammen. Auth und ZETA Client gehören zur Basis; das Push-Modul ist optional. DiPag erhält einen eigenen FdV-Modulsteckbrief. G-App PTV, DiPag FdV PTV und Herstellerverzeichnis liegen jeweils als Entwurf 1.0.0-0, Dokument 1.0.0_CC vor. A_30112 betrifft die TR-03185-Zertifizierung des Entwicklungsprozesses beim Hersteller; A_30113 die anwendbaren Produktanforderungen der TR-03161 Teil 1 und das Produktgutachten. Die vier HCSA-Kacheln beschreiben die ITL-Produktidee; ePA-FdV und TI-M Client ePA besitzen eigene Produktscopes.

• gemSpec_App 1.0.0_CC · §§ 2–4.2 · A_30112 / A_30113 ↗
• Draft_App_26_1 ZIP · G-App PTV / DiPag FdV PTV / gemVZ_Afo_Herst_App · jeweils / each 1.0.0-0, V1.0.0_CC ↗

ZETA 1.3.2 ist die freigegebene Quelle für die hier erläuterte allgemeine Client-/Guard-Architektur. Der G-App-Entwurfssteckbrief nennt dagegen gemSpec_ZETA 2.0.1_CC und gemSpec_Krypt 2.49.1 als Abhängigkeiten. Der exakte ZETA-Quelltext 2.0.1_CC und eine Berichtigung dieses Pins konnten im geprüften öffentlichen Quellenbestand nicht verifiziert werden; dieser Teil des G-App-Abgleichs bleibt offen. Der öffentlich vorliegende Entwurf 2.0.0_CC vom 09.07.2026 ergänzt den mobilen Architekturkontext. Er wird ebenso wie 1.3.2 mit seinem eigenen Geltungsbereich erläutert und ersetzt die G-App-Abhängigkeit 2.0.1_CC nicht.

• G-App PTV 1.0.0-0, V1.0.0_CC · Tabelle / Table 1, S. / p. 6 · im / in ZIP ↗
• gemSpec_ZETA 1.3.2 · 26.06.2026 ↗
• Draft_ZETA_26_2 · veröffentlicht / published: 2.0.0_CC ↗
• ZETA Guard Verzeichnis 1.3.0-0 / 1.0.2 · Tabelle / Table 1: ZETA 1.3.2 ↗

Der Vertrag nutzt FHIR R4 4.0.1 und das Paket de.gematik.dipag 1.0.8. RE-PS übermittelt Rechnungen an Patient/{id}/$invoice-submit. Das FdV sucht eigene DocumentReference-Ressourcen, ruft Inhalte über DocumentReference/$retrieve ab und verwaltet den Rechnungsvorgang über $change-status, $process-flag und $erase auf DocumentReference/{id}; AuditEvent dient dem Nutzerprotokoll. RE-PS und KTR-PS können Dokumente über $retrieve mit Dokumenttoken abrufen. Claims und Scopes bleiben rollenspezifisch. Die Einreichung zur Erstattung erfolgt im MVP über andere Wege, etwa die Teilen-Funktion des FdV; sie ist nicht der RE-PS-Aufruf $invoice-submit.

• gemSpec_DiPag_FD 1.1.3_CC · A_25847 · §§ 5.1.6.1, 5.4.1–5.4.3 ↗
• DiPag IG 1.0.8 · FdV / RE-PS / ITSys-KTR ↗
• de.gematik.dipag 1.0.8 · CapabilityStatementFD / OperationDefinition ↗

Der Dokumenttoken ist der Identifier mit dem System https://gematik.de/fhir/sid/dipag-token; er ist nicht die technische DocumentReference.id. Das CapabilityStatement sieht DocumentReference-Suche und Operationen vor, keinen direkten DocumentReference-read. Für $invoice-submit gilt das Eingangsprofil dipag-dokumentenmetadaten-eingang; der Fachdienst verwendet dipag-dokumentenmetadaten-intern. $process-flag ersetzt den vollständigen änderbaren Markierungssatz. Ohne Markierungen werden diese entfernt; persönlich und abgerufen durch KTR bleiben ausgenommen. Die persönlichen Bearbeitungszustände sind offen, erledigt und papierkorb. Sie sind keine Erstattungsentscheidung eines Kostenträgers.

• de.gematik.dipag 1.0.8 · Retrieve / Submit / ProcessFlag / CapabilityStatementFD / Rechnungsstatus ↗

Rechnungsmetadaten für RE-PS und KTR-PS dürfen keine Rückschlüsse auf die vom Versicherten verwalteten Status oder Markierungen erlauben. Das Berechtigungsmanagement ist eine separate HTTP-REST-Schnittstelle mit KVNR-Claim sowie permission.r zum Lesen und permission.u zum Bearbeiten. Im MVP verwaltet der FD ausschließlich Rechnungsversandberechtigungen: Sie entstehen bei der ersten Rechnung des Rechnungserstellers; Versicherte können bestehende Berechtigungen auflisten, entziehen und wieder erteilen. Daraus folgt keine allgemeine Freigabe persönlicher Rechnungsmetadaten oder beliebiger medizinischer Daten.

• gemSpec_DiPag_FD 1.1.3_CC · A_29954 / A_29955 / A_25967-01 / A_26043-01 ↗

Die 15 UX-Anforderungen des App-Entwurfs werden hier in neun Nutzerbereiche zusammengefasst: Abruf, Übersicht und Details einschließlich angereichertem PDF, manuelle Statusänderung, Markierungen/Notizen, endgültiges Löschen eines Rechnungsvorgangs, Einsehen und Export des Nutzerprotokolls, Berechtigungsverwaltung, Teilen und Kontoverwaltung einschließlich Kontolöschung. Teilen unterscheidet Rechnungs-PDF und EPC-/GiroCode als QR-Bild für Banking-Apps sowie die Zwischenablage für Empfänger, IBAN und Verwendungszweck. Papierkorb, endgültiges Löschen eines Rechnungsvorgangs und Kontolöschung sind unterschiedliche Aktionen. Diese Anforderungen beschreiben den geplanten App-Scope; die Website bietet ausgewählte synthetische Beispielaktionen.

• gemSpec_App 1.0.0_CC · § 4.3 · A_30077 / A_30078 / A_30082 / A_30083 / A_30084 / A_30179 / A_30104 / A_30080 / A_30081 / A_30079 / A_30138 / A_30103 / A_30110 / A_30180 / A_30181 ↗

Der DiPag-Fachdienst protokolliert unter anderem Änderungen an Markierungen mit Dokumentbezug und verantwortlichem Akteur. Ein Nutzerprotokolleintrag ist nach drei Jahren ab Zugriffszeitpunkt innerhalb eines Monats zu löschen. Das FdV stellt Einsicht und Export bereit. Die lokale Aktivitätsliste dieser Demo bleibt flüchtige Bedienhistorie; sie ersetzt weder das Fachdienst-Nutzerprotokoll noch dessen Aufbewahrungs- und Löschregeln.

• gemSpec_DiPag_FD 1.1.3_CC · A_25987 / A_29995 ↗
• gemSpec_App 1.0.0_CC · A_30080 / A_30081 ↗

In gemSpec_DiPag_FD 1.1.3_CC nennt A_25849-01 die Operation $invoice-submit, A_25880 dagegen $dipag-submit. OperationDefinition Submit und CapabilityStatementFD im Paket 1.0.8 verwenden beide invoice-submit. Die Operationskarte auf dieser Seite folgt ausdrücklich diesem Paket. Die abweichende PDF-Stelle bleibt als Quellenwiderspruch dokumentiert; der Paketbefund ist keine offizielle Berichtigung des PDF.

• gemSpec_DiPag_FD 1.1.3_CC · A_25849-01 / A_25880 ↗
• de.gematik.dipag 1.0.8 · Submit / CapabilityStatementFD ↗

Service Discovery bestimmt den Guard und seine Endpunkte. Registrierungsdaten einschließlich client-id werden pro Guard geführt; der mobile Registrierungsablauf bindet lokal erzeugte geschützte Schlüssel, OIDC-Nutzerauthentifizierung, Attestierung und eine Offband-Bestätigung ein. Für Sitzungen sind OAuth mit PKCE, sichere Access-/Refresh-Token- und DPoP-Schlüsselverwaltung sowie Refresh-Token-Rotation beschrieben. Nutzer können registrierte Clients einsehen und deregistrieren. Dienstspezifische Berechtigungen bleiben separat. Der Zwölf-Screen-Flow illustriert Entscheidungen an einer fiktiven Ressource demo.document; er implementiert diesen Protokollablauf nicht. Die offenen mobilen Details in 1.3.2 bleiben vom G-App-Versionsabgleich getrennt.

• gemSpec_ZETA 1.3.2 · §§ 5.8.2–5.8.5 · A_28465 / A_28524 / A_25432-01 / A_25769 / A_25733 / A_25781 / A_25782 ↗

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.

• gemSpec_ZETA 2.0.0_CC · § 5.3.2 · A_29658 / A_29809 / A_29810 / A_29659 · Kontext, kein Ersatz für / context, not a substitute for 2.0.1_CC ↗

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.

• G-App PTV 1.0.0-0 / 1.0.0_CC · Tabellen / Tables 1, 4–5, 7–10 ↗
• ZETA 2.0.0_CC · ausschließlich ID-Vergleich / ID comparison only ↗

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.

• gemSpec_ZETA 1.3.2 · § 1.3 · Anwendbarkeit / applicability ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• gemSpec_ZETA 1.3.2 · A_25340-01 / A_28425-01 / A_28426 / A_28464 / A_28465 / A_28524 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• gemSpec_ZETA 1.3.2 · A_25667 / A_25668 / A_28963 / A_28525-01 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• gemSpec_ZETA 1.3.2 · A_26681-01 / A_26480 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• gemSpec_ZETA 1.3.2 · A_28837 / A_25661 / A_25662 / A_25663 / A_25665 / A_25782 / A_25733 / A_25734 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• gemSpec_ZETA 1.3.2 · A_28827 / A_28803 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗