A_22838 - Entgegennahme von Sperrmeldungen

Der Anbieter des sektoralen IDP MUSS Sperrmeldungen von Sperrberechtigten, zu von ihm verantworteten Authentisierungsmitteln, jederzeit entgegennehmen und das betroffene Authentisierungsmittel oder auch den gesamten Zugang des Nutzers daraufhin unverzüglich sperren. [<=]

A_22690 - Darstellen der Voraussetzungen für sicheren Betrieb des Produkts im Betriebshandbuch

Der Hersteller des sektoralen IDP MUSS für sein Produkt im dazugehörigen Betriebshandbuch leicht ersichtlich darstellen, welche Voraussetzungen vom Betreiber und der Betriebsumgebung erfüllt werden müssen, damit ein sicherer Betrieb des Produktes gewährleistet werden kann. [<=]

A_22691 - Sicherer Betrieb des Produkts nach Betriebshandbuch

Der Anbieter eines sektoralen IDP MUSS die im Betriebshandbuch des eingesetzten sektoralen IDP beschriebenen Voraussetzungen für den sicheren Betrieb des Produktes gewährleisten. [<=]

A_23044 - Unterstützung von Diensten außerhalb der TI

Der Anbieter des sektoralen IDP KANN die Anmeldung an weiteren Diensten außerhalb der Föderation unterstützen und diesen die Authentisierung von Nutzern auf Basis der bestehenden digitalen Identitäten anbieten. [<=]

A_23337-01 - Mindestvorgaben für Schlüssel von sektoralen IDPs als Teilnehmer der TI-Föderation

Ein sektoraler IDP als Teilnehmer der TI-Föderation MUSS bei dem eingesetzten Schlüsselmaterial (Signatur,  mTLS Clientzertifikat, Entity Statement, etc.), folgende Vorgaben umsetzen:

1. Alle verwendeten Schlüssel MÜSSEN ein Sicherheitsniveau von 120 Bit ermöglichen (vgl. [gemSpec_Krypt#5 "Migration 120-Bit Sicherheitsniveau"]).
2. Alle ECC-Schlüssel MÜSSEN auf einem folgenden der Domainparameter (Kurven) basieren:
1. P-256 oder P-384 [FIPS-186-4]

A_22239 - Schützenswerte Objekte

Der Anbieter eines sektoralen Identity Provider MUSS die folgenden kryptographischen Objekte als schützenswerte Objekte in seinem Sicherheitskonzept berücksichtigen: (a) Private Schlüssel, (b) Öffentlicher Schlüssel, (c) Öffentliche Schlüssel von registrierten Clients, (d) Datensätze zu den einzelnen Nutzern, (e) Authentisierungsinformationen von Sperrberechtigten, (f) Dokumentation über beauftragte und durchgeführte Sperrungen, (g) Statusinformationen, (h) Authentisierungsinformationen zur Authentisierung von internen Akteuren bzw. Rollen, (i) Protokolldaten, (j) Konfigurationsdaten. [<=]

A_22240 - Berücksichtigung OWASP-Top-10-Risiken

Der Anbieter des sektoralen Identity Provider MUSS Maßnahmen zum Schutz vor den zum Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken umsetzen und dokumentieren, wie es vorgesehen ist, ebenfalls auf die nach dem Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken zu reagieren. [<=]

A_22241 - Interner Datenaustausch der Komponenten des sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS beim internen Datenaustausch die Integrität, Authentizität und Vertraulichkeit der Daten sichern. [<=]

A_22242-01 - Gesicherte externe Schnittstellen des sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS für den Datenaustausch mit anderen Rollen und Diensten Mechanismen zur Sicherung der Datenintegrität, der Authentizität und der Vertraulichkeit der Daten zur Verfügung stellen. Hierzu gehören z. B. die Schnittstellen vom Anbieter eines sektoralen Identity Provider zur Attributbestätigenden Stelle für die Übermittlung der Attribute bei der Einrichtung eines Nutzers sowie von Supportfälle.
[<=]

A_22243-02 - Nutzung bestehender Datensätze bei Registrierung für Endanwender (Versicherte)

Der Anbieter des sektorale Identity Provider SOLL für die Registrierung der Endanwender die bestehenden Datensätze der Endanwender (Versicherte) beim Kostenträger verwenden, so wie sie für eine Identifikation nach [GKV-SV Richtlinie "Kontakt mit Versicherten] beschrieben wurden. [<=]

A_22244 - Trennung der Betriebsumgebungen

Der Anbieter eines sektoralen Identity Provider MUSS sicherstellen, dass das Testsystem von dem Produktivsystem technisch, organisatorisch und betrieblich so getrennt wird, dass keine gegenseitige Beeinflussung und keine Verwechslung möglich sind.  [<=]

A_22245 - Datenschutzgerechte Einrichtungs- und Sperrprozesse

Der Anbieter eines sektoralen Identity Provider MUSS die Einrichtungs- und Sperrprozesse datenschutzgerecht ausgestalten, d.h. insbesondere sind für die Verarbeitung der Antrags- und Sperrauftragsdaten die Datenschutzgrundsätze gemäß Art. 5 DSGVO zu berücksichtigen, sowie die technischen und organisatorischen Maßnahmen nach Art. 25 und Art. 32 DSGVO zu treffen. [<=]

A_22246 - Löschung von Nutzerinformationen

Der Anbieter eines sektoralen Identity Provider MUSS die Attributsdaten und Sperraufträge zu einem Nutzer unverzüglich löschen, sobald die gesetzlichen oder vertraglichen Aufbewahrungsfristen erreicht sind. [<=]

A_22839 - Fehlerprotokollierung

Falls der Anbieter eines sektoralen IDP eine Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung durchführen muss, MÜSSEN die Protokolldaten entsprechend dem Datenschutzgrundsatz der Datenminimierung (gemäß Art. 5 Abs. 1 Satz 1 lit.c DSGVO unter Berücksichtigung der Art. 25, 32 DSGVO) derart gestaltet sein, dass nur personenbezogene Daten in der Art und dem Umfang enthalten sind, wie sie zur Behebung erforderlich sind. Insbesondere MUSS der Anbieter eines sektoralen IDP sicherstellen, dass ein Bezug zwischen Nutzer und Fachdienst aus den Protokollen nicht ersichtlich sein. [<=]

A_23021 - Trennung von Diensten der Föderation und weiteren unterstützten Anwendungen

Wenn der Anbieter eines sektoralen Identity Providers die Anmeldung an weiteren Dienste außerhalb der Föderation unterstützt MUSS sichergestellt sein, dass die Anforderungen an Verfügbarkeit, Performance und Sicherheit der Schnittstellen für Fachdienste der Föderation erfüllt werden. [<=]

A_23023 - Sicherung externen Schnittstellen gegen bösartige Eingaben

Der sektorale IDP MUSS sicherstellen, dass alle Eingabewerte, welche vom sektoralen IDP über externe Schnittstellen (siehe Tabelle "Schnittstellenübersicht") entgegengenommen und verarbeitet werden, auf schadhafte Werte geprüft werden.
[<=]

A_23022 - Prozesse zum Ändern oder Löschen von Daten der Authentisierungsprozesse

Werden Daten der Authentisierungsprozesse im sektoralen IDP ohne direkte Beteiligung des Nutzers geändert oder gelöscht, MUSS der Anbieter des sektoralen IDP sicherstellen, dass die operativen Prozesse hierfür ausschließlich im 4-Augen-Prinzip durchgeführt werden. Der Nutzer MUSS über die Änderungen informiert werden und die Änderung MUSS erkennbar sein.
[<=]

A_23499 - Prozesse zum Ändern oder Löschen von personenbezogenen Daten

Werden personenbezogene Daten im sektoralen IDP geändert oder gelöscht, ohne dass der Betroffene direkt involviert ist, so MUSS der Anbieter des sektoralen IDP sicherstellen, dass die operativen Prozesse dazu ausschließlich im 4-Augen-Prinzip ausgeführt werden. Der Nutzer ist über die Änderungen zu informieren. Personenbezogene Daten, die über den Synchronisationsprozess mit den Kassensystemen geändert oder gelöscht werden, sind von diesem operativen Prozess nicht betroffen. [<=]

A_22824 - Verhalten bei Vollauslastung

Der Anbieter eines sektoralen Identity Provider MUSS den Dienst so konfigurieren, dass bei Vollauslastung der Systemressourcen im sektoralen Identity Provider keine weiteren Verbindungen angenommen werden und dieser stattdessen mit dem HTTP-Statuscode "429 - Too Many Requests" antwortet. [<=]

A_22692 - Kriterien für die Standortwahl von Rechenzentren

Der Anbieter des sektoralen IDP MUSS nachweisen, dass er die aktuellen Empfehlungen des BSI bei der Standortwahl seiner Rechenzentren vollumfänglich umsetzt. Der Anbieter des sektoralen IDP MUSS Unterschreitungen der Empfehlungen des BSI begründen und die Abmilderung der Risiken begründet nachweisen. Der Anbieter des sektoralen IDP MUSS einen Prozess für die Umsetzung zukünftige Empfehlungen des BSI bei der Standortwahl seiner Rechenzentren nachweisen. [<=]

A_22250 - Schutz der Verbindung zum sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS sicherstellen, dass die Schnittstellen des sektoralen Identity Provider nur über eine gegen Abhören, Manipulation und Replay-Angriffe geschützte Verbindung genutzt werden können. [<=]

A_22512 - Schutz der Schnittstellen des sektoralen Identity Provider ins Internet

Der Anbieter eines sektoralen IDP MUSS sicherstellen, dass seine Schnittstellen ins Internet an allen Standorten durch einen DDoS-mitigierenden Dienstleister geschützt werden. [<=]

A_23099 - Datenverarbeitung innerhalb der Europäischen Union

Der Anbieter eines sektoralen IDP MUSS im Sinne der vollständigen DSGVO-Konformität sicherstellen, dass die Datenverarbeitung innerhalb der Europäischen Union erfolgt und dieses auch nachweisen. [<=]

A_22694 - Georedundanz des sektoralen Identity Provider

Der Anbieter des sektoralen Identity Provider MUSS diesen an mindestens zwei Standorten betreiben.
Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
Eine getrennte Adressierung durch zugreifende Anwendungsfrontends und Fachdiensten MUSS hierdurch möglich sein - alternativ ist diese Adressierung auch durch den DDoS-mitigierenden Dienstleister erlaubt.
[<=]

A_22695 - Mindestabstand für Georedundanz des sektoralen Identity Provider

Ab dem 31.12.2023 MUSS der Anbieter des sektoralen Identity Provider seinen Dienst an zwei Standorten gemäß A_22692 betreiben, wobei eine Unterschreitung des Abstandes von 100 km gemäß A_22692 nicht zulässig ist. [<=]

A_22506-01 - Unabhängiges Bedienpersonal pro Standort des sektoralen Identity Provider

Der Anbieter des sektoralen Identity Provider MUSS pro Standort ein unabhängiges Bedienpersonal vorhalten, um die Risiken der Standortvorgaben des BSI tragen zu können. [<=]

A_22508 - Ausschluss von nicht erlaubten Authenticator-Modul Versionen (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS von ihm nicht erlaubte Authenticator-Module (anhand der Versionsnummern) ablehnen, von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch mit dem Status-Code 79105 in den Rohdaten protokollieren. [<=]

A_22509 - Ausschluss bei fehlenden Authenticator-Modul Versionsnummern (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS Authenticator-Module mit fehlenden Versionsnummern ablehnen, von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch in den Rohdaten mit dem Error-Code 403 protokollieren. [<=]

A_22931 - Zu verwendende Produktversion in der Kommunikation zum IDP

Das Authenticator-Modul MUSS in Requests an den IDP seine Produktversion übermitteln. [<=]

A_22253 - Ausschluss bestimmter Authenticator-Modul Versionen von der Kommunikation

Der sektorale Identity Provider MUSS die vom Authenticator-Modul mitgeteilte Versionsnummer erkennen und festgelegte Versionsnummern über eine blockinglist von einer Kommunikation ausschließen können. [<=]

A_22254-01 - Ausschluss von Authenticator-Modul Versionen (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS auf Anweisung der gematik Authenticator-Module mit bestimmten Versionsnummern von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch in den Rohdaten protokollieren. [<=]

A_23192 - Maximale Verwendungsdauer für Schlüssel

Der Anbieter des sektoralen Identity Provider MUSS Schlüsselpaare welche zur Signatur von Entity Statements bzw. ID_TOKEN oder zur TLS-Authentisierung verwendet werden, nach maximal 398 Tagen austauschen. [<=]

A_22864 - Umsetzung von Operationen in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

Der sektorale IDP MUSS die Verarbeitung aller Operationen welche die Ziele gemäß A_23018, A_23019 und A_22959 gewährleisten in einer Vertrauenswürdigen Ausführungsumgebung umsetzen. Die HTTP-Verbindungen zwischen Fachdiensten und sektoralem IDP MÜSSEN als mTLS-Verbindungen ausgelegt werden, welche innerhalb der VAU terminieren. [<=]

A_23002 - sicherer Betrieb der Vertrauenswürdigen Ausführungsumgebung (VAU)

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass alle Operationen, welche die Ziele gemäß A_23018, A_23019 und A_22959 gewährleisten, in einer vertrauenswürdigen Ausführungsumgebung umgesetzt werden. [<=]

A_23018 - Anforderungen an den Schutz vor Profilbildung

A_23019 - Anforderungen an den Schutz der Operationen in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf das Schlüsselmaterial der TLS-Verbindungen haben.
  
• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf die für die Signatur von ID_TOKEN verwendeten Schlüssel haben.
  
• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf die im AUTHORIZATION_CODE und in der Request-URI kodierten Informationen haben.
  

A_22959 - Prozess zur Consent-Freigabe durch den Nutzer

Der Anbieter des sektoralen IDP MUSS dafür sorgen, dass der Prozess zur Freigabe des Consent durch den Nutzer verschlüsselt und nicht einsehbar für Dritte oder den Betreiber selbst erfolgt. [<=]

A_22829 - Anbieter sektoraler IDP Speicherung Schlüsselmaterial in HSM

Der Anbieter des sektoralen IDP MUSS das private Schlüsselmaterial für kryptografische Verfahren in einem HSM speichern, dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage.
Die Prüftiefe MUSS mindestens: 

1. FIPS 140-2 Level 3 oder
2. Common Criteria EAL 4+ erweitert um AVA_VAN.5 entsprechen

A_23205 - Prozesse für die Verwaltung des HSM

Der Anbieter des sektoralen IDP MUSS Prozesse für die Verwaltung der Systeme der VAU etablieren, welche die Authentizität und Integrität der Verarbeitungskontexte systematisch von einem kryptographischen Root-of-Trust ableiten, der in einem HSM gemäß A_22829 verwaltet wird.
Der Anbieter des sektoralen IDP MUSS bei der Ableitung ein Vertrauensniveau erreichen, welches für den Schutzbedarf der in der VAU verarbeiteten Daten angemessenen ist und das auf Attestation der genutzten Systeme sowie ggf. auf der Prüfung von Signaturen der geladenen Software inklusive ihrer Konfiguration basiert.
Der Anbieter des sektoralen IDP MUSS für die Verwaltung des Root-of-Trust ein Mehraugenprinzip umsetzen und - soweit für systematischen Ausschluss einseitig durch den Anbieter durchführbarer Manipulationen erforderlich - eine Einbeziehung der gematik vorsehen.
Der Anbieter des sektoralen IDP MUSS der gematik dabei eine Remote-Teilnahme an den erforderlichen Zeremonien ermöglichen.  [<=]

A_22830 - sektoraler IDP – Verarbeitungskontext der VAU

Der Verarbeitungskontext des sektoralen IDP MUSS sämtliche physikalischen Systemkomponenten sowie sämtliche Softwarekomponenten umfassen, deren Sicherheitseigenschaften sich auf den Schutz der personenbezogenen Daten vor Zugriff durch Unbefugte bei ihrer Verarbeitung im Klartext auswirken können. [<=]

A_22840 - Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass sämtliche schützenswerten Daten vor einer Speicherung außerhalb der VAU verschlüsselt werden. Dies betrifft auch Daten zu Logging und Protokollierung. [<=]

A_22841 - Schutz der Persistenzschlüssel durch ein HSM

Schlüsselmaterial, dass zur Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten genutzt wird, MUSS entweder durch ein HSM geschützt in den Verarbeitungskontext der VAU eingebracht werden, oder in einem HSM verbleiben. [<=]

A_22842 - Bereitstellung Persistenzschlüssel

Das HSM der VAU des sektoralen IDP MUSS eine Schnittstelle zum Abruf symmetrischer Persistenzschlüssel bereitstellen. Erzeugte Schlüssel für die Persistierung der Daten MÜSSEN eineindeutig einem Nutzer zugeordnet sein. [<=]

A_22843 - Geschützte Weitergabe von Daten an autorisierte Nutzer durch die VAU

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass sämtliche schützenswerten Daten ausschließlich über TLS-gesicherte Verbindungen weitergegeben werden. [<=]

A_22844 - Transportverschlüsselte Übertragung von Daten mit Fachdiensten

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass er nur mTLS-gesichert mit Fachdiensten kommuniziert. [<=]

A_22847 - Authentisierung gegenüber Clients

Der Verarbeitungskontext des sektoralen IDP MUSS sich gegenüber Clients, welche mit ihm kommunizieren, mit einem TLS-Zertifikat ausweisen, auf dessen privaten Schlüssel der Betreiber des sektoralen IDP keinen Zugriff hat. [<=]

A_23006 - Subdomäne für Webservice-Endpunkte in der VAU

Der Verarbeitungskontext des sektoralen IDP MUSS diese Endpunkte anbieten:

• Endpunkt für Authorization Requests
• Endpunkt für Pushed Authorization Requests
• Token-Endpunkt

A_22943 - Richtlinien zum TLS-Verbindungsaufbau

Der Anbieter des sektoralen IDP MUSS dafür sorgen, dass der Verarbeitungskontext des sektoralen IDP sich beim TLS-Verbindungsaufbau über das Transportnetz gegenüber dem Client mit einem TLS-Zertifikat eines Herausgebers gemäß [CAB-Forum] authentisiert. Der Anbieter MUSS dafür sorgen, dass Clientsysteme beim TLS-Verbindungsaufbau eine vereinfachte Zertifikatsprüfung mit TLS-Standardbibliotheken durchführen können.  [<=]

A_22980 - Grundlage zur Prüfung der TLS-Zertifikate mittels Certificate Transparency

Der Anbieter des sektoralen IDP MUSS die TLS-Zertifikate, welche in seinem Verarbeitungskontext terminieren, aus einer CA beziehen, welche Certificate Transparency gemäß RFC 6962 / RFC 9162 unterstützt und täglich prüfen und sicherstellen, dass für die zur Verbindungen in den Verarbeitungskontext der VAU vorgesehen Domänen keine unbekannten Zertifikate im Certificate Transparency Log gelistet werden. Im Fehlerfall MUSS ein "Security Incident" (gemäß 3.4 gemRL_Betr_TI) erstellt werden.  [<=]

A_22981 - Grundlage zur Prüfung der TLS-Zertifikate mittels Certification Authority Authorization (CAA) Records

Der Anbieter des sektoralen IDP MUSS für die TLS-Zertifikate welche in seinem Verarbeitungskontext terminieren Certification Authority Authorization (CAA) DNS Resource Records nach RFC 6844 bereitstellen, welche die Validität der ausstellenden CA verifizieren.  [<=]

A_22982 - Bereitstellung der öffentlichen Schlüssel der TLS-Zertifikate

Der Anbieter des sektoralen IDP MUSS die öffentlichen Schlüssel der TLS-Zertifikate, welche in seinem Verarbeitungskontext terminieren, dem Federation Master bereitstellen. Der organisatorische Prozess zur Schlüsselübergabe ist in [gemSpec_IDP_FedMaster] beschrieben. [<=]

A_22848 - Isolation zwischen Datenverarbeitungsprozessen mehrerer Verarbeitungskontexte der VAU

Die VAU des sektoralen IDP MUSS die in ihr ablaufenden Verarbeitungen für die Daten eines Verarbeitungskontextes von den Verarbeitungen für die Daten anderer Verarbeitungskontexte in solcher Weise trennen, dass mit technischen Mitteln ausgeschlossen wird, dass die Verarbeitungen eines Verarbeitungskontextes schadhaft auf die Verarbeitung eines anderen Verarbeitungskontextes einwirken können. Die VAU des sektoralen IDP MUSS dabei insbesondere verhindern, dass die Verarbeitungen von Daten innerhalb eines Verarbeitungskontextes zur fehlerhaften Ausstellungen von Identitätsbestätigungen bei einem Authentifizierungsvorgang in einem anderen Verarbeitungskontext führen könnte. [<=]

A_22849 - Isolation der VAU von Datenverarbeitungsprozessen des Anbieters

Die VAU des sektoralen IDP MUSS die in ihren Verarbeitungskontexten ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Anbieters trennen und damit gewährleisten, dass sowohl Dritte als auch der Betreiber des sektoralen IDP selbst vom Zugriff auf die in der VAU verarbeiteten schützenswerten Daten ausgeschlossen ist.
[<=]

A_22850 - Ausschluss von Manipulationen an der Software der VAU

Die VAU des sektoralen IDP MUSS eine Manipulation der eingesetzten Software erkennen und eine Ausführung der manipulierten Software verhindern. [<=]

A_22851 - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU des sektoralen IDP MUSS die Integrität der eingesetzten Hardware schützen und damit insbesondere Manipulationen an der Hardware sowohl durch Dritte als auch der Betreiber des sektoralen IDP ausschließen. [<=]

A_22852 - Kontinuierliche Wirksamkeit des Manipulationsschutzes der VAU

Die VAU des sektoralen IDP MUSS den Ausschluss von Manipulationen an der Hardware und der Software sowohl durch Dritte als auch der Betreiber des sektoralen IDP mit Mitteln umsetzen, deren dauerhafte und kontinuierliche Wirksamkeit gewährleistet werden kann. [<=]

A_22853 - Ausschluss von Manipulationen über physische Angriffe

Die VAU des sektoralen IDP MUSS mit technischen und/oder organisatorischen Mitteln ausschließen, dass ein Angreifer aus dem betrieblichen Umfeld des IDP physische Angriffsmittel zur Kompromittierung der VAU zum Einsatz bringen kann. [<=]

A_22854 - Nutzdatenbereinigung vor physischem Zugang zu Systemen der VAU

Die VAU des sektoralen IDP MUSS mit technischen und/oder organisatorischen Mitteln sicherstellen, dass physischer Zugang zu Hardware-Komponenten der Verarbeitungskontexte nur erfolgen kann, nachdem gewährleistet ist, dass aus ihnen keine Nutzdaten extrahiert werden können. [<=]

A_22868 - Private Schlüssel im HSM

Der sektorale IDP MUSS folgende private Schlüssel in einem Hardware Security Module (HSM) erzeugen und anwenden: 

• die Schlüssel zur Signatur von Token und Entity Statements
• die Schlüssel der TLS-Zertifikate für die sichere Verbindung zum Verarbeitungskontext
  

A_22855 - HSM-Kryptographieschnittstelle verfügbar nur für Instanzen der VAU

Die VAU des sektoralen IDP MUSS mit technischen Mitteln die Manipulationen sowohl durch Dritte als auch den Betreiber des sektoralen IDP ausschließen und gewährleisten, dass nur Instanzen der VAU-Zugriff auf die Kryptographie Schnittstelle des HSM zur Nutzung des privaten Schlüsselmaterials für ihre TLS-Zertifikate und die Signaturschlüssel für die Token und Entity Statements erhalten können. [<=]

A_22856 - Konsistenter Systemzustand des Verarbeitungskontextes der VAU

Die VAU des sektoralen IDP MUSS sicherstellen, dass ein konsistenter Zustand des Verarbeitungskontextes auch bei Bedienfehlern oder technischen Problemen immer erhalten bleibt bzw. wiederhergestellt werden kann. [<=]

A_22567-01 - Informationsverpflichtung über Mandanten des Anbieter sek IDP KTR

Der Anbieter sek IDP KTR MUSS der gematik initial zur Zulassung und danach jeweils bei Änderungen tagesaktuell die Liste der Mandanten (Versicherungen) mitteilen, für deren Versicherte er den Dienst anbietet.
Zusätzlich MUSS der Anbieter sek IDP KTR für GKV-Kassen die gemIK [gemäß A_25078] und die Telematik-ID der Kasse aus dem "Verfahren zur Herausgabe der SMC-B für Kostenträger" nennen, in welchem der GKV-SV die Echtheit der Kasse bereits bestätigt hat und für Unternehmen nach §362 (1) SGB V (PKV-Kassen, Postbeamtenkrankenkasse, Bundeswehr ... ) die gemIK [gemäß A_25078] und die Telematik-ID des Unternehmens aus dem "Verfahren zur Herausgabe der SMC-B" nennen. Die Beauftragung der Kasse bzw. des Unternehmens ist der Meldung schriftlich als Erklärung beizufügen.

Hinweis: Die Benachrichtigung an die gematik kann per E-Mail (S/MIME) an transition@gematik.de erfolgen.
[<=]

A_25184 - Konkretisierung der Mandantenbereitstellung des Anbieter sek IDP KTR in der TU für den Test

Der Anbieter sek IDP KTR MUSS für den TU-Mandanten [gem. A_25155] jeweils bis zu 500 Testidentitäten nach Vorgabe der gematik bereitstellen. Die Bereitstellung der Test-Identitäten durch den Anbieter MUSS innerhalb von 28 Kalendertagen nach Aufforderung durch die gematik erfolgen. Dabei MUSS der Anbieter die Verknüpfung dieser Testidentitäten mit Identitätsmitteln der gematik unterstützen.
[<=]

A_25186 - Konkretisierung der Mandantenbereitstellung des Anbieter sek IDP KTR in der RU für den Test

Der Anbieter sek IDP KTR MUSS für den RU-Mandanten [gem. A_25155] jeweils bis zu 500 Testidentitäten nach Vorgabe der gematik bereitstellen. Die Bereitstellung der Test-Identitäten durch den Anbieter MUSS innerhalb von 28 Kalendertagen nach Aufforderung durch die gematik erfolgen. Dabei MUSS der Anbieter die Verknüpfung dieser Testidentitäten mit Identitätsmitteln der gematik unterstützen. [<=]

A_23053 - Bereitstellung von Testinstanzen

Der Anbieter des sektoralen IDPs MUSS nach der Zulassung neben der produktiven Instanz weitere Testinstanzen des sektoralen IDPs bereitstellen. Das sind zunächst eine RU-Instanz und eine TU-Instanz. [<=]

A_23054 - Skalierung von Testinstanzen

Der Anbieter des sektoralen IDPs MUSS zusätzliche Testinstanzen über einen Business-Service Katalog anbieten. Diese KÖNNEN unterschiedliche Performance und Lastanforderungen ausweisen. [<=]

A_23055 - Aufbau RU-Instanz

Der Hersteller des sektoralen IDPs MUSS die RU-Instanz iterativ aufbauen und der gematik frühzeitig einen Zugriff auf Zwischenstände ermöglichen. [<=]

A_23056 - Bereitstellung der TU-Instanz

Der Hersteller des sektoralen IDPs MUSS die TU-Instanz zur Zulassung bereitstellen. [<=]

A_23057 - Version der TU-Instanz

Der Anbieter des sektoralen IDP SOLL dafür sorgen, dass die Version der TU-Instanz - außer für die Abnahme einer neuen Version - der der produktiven Instanz entspricht. [<=]

A_23058 - Änderung der Version der RU-Instanz

Der Hersteller des sektoralen IDPs KANN die Version der RU-Instanz während der Entwicklung nach Absprache mit der gematik ohne Change-Prozess ändern. Downtimes MÜSSEN dabei der gematik ankündigt werden. Dadurch sollen schnelle Feedbackschleifen während der Entwicklung ermöglicht werden. [<=]

A_23163 - Anpassung RU-Instanz

Möchte ein Hersteller oder Anbieter des sektoralen IDP seine RU-Instanz anpassen, so MUSS dies in Abstimmung mit dem Testmanager der gematik geschehen. [<=]

A_23060 - Testversion des Authenticator-Moduls für Testinstanzen

Der Anbieter des sektoralen IDPs MUSS eine Testversion seines Authenticator-Moduls in einer App bereitstellen, die mit allen Testinstanzen des sektoralen IDPs genutzt werden kann. Das können verschiedene Apps oder eine konfigurierbare sein. Die Testversion MUSS kurzfristig und auf Anfrage an die gematik, aber auch an Dritte - z. B. DIGA-Hersteller - bereitgestellt werden. [<=]

A_23061 - Betriebssysteme der Testversion des Authenticator-Moduls

Der Anbieter des sektoralen IDPs MUSS eine Testversion seines Authenticator-Moduls in einer App für alle von ihm produktiv unterstützten Betriebssysteme bereitstellen. [<=]

A_23062 - Funktionsumfang der Testversion des Authenticator-Moduls

Der Anbieter des sektoralen IDPs MUSS eine Testversion des Authenticator-Moduls bereitstellen, die funktional der Produktivversion entspricht. [<=]

A_23063 - Bereitstellung einfacher Testidentitäten

Der Anbieter des sektoralen IDPs MUSS  einfache Testidentitäten für alle seine Testinstanzen bereitstellen. Diese MÜSSEN mindestens ein Authentisierungsverfahren anbieten, so dass sie in Tests verwendet werden können.  
Der Anbieter des sektoralen IDPs MUSS zunächst 50 einfache Testidentitäten je Testinstanz bereitstellen. Auf Anfrage der gematik MÜSSEN bei Bedarf weitere einfache Testidentitäten angelegt werden. [<=]

A_23300 - Authentisierungsverfahren für Testautomatisierung

Mindestens eines der Authentisierungsverfahren der vom Anbieter des sektoralen IDP bereitgestellten Testidentitäten SOLL automatisierbar sein. [<=]

A_23065 - Bereitstellung Authentisierungsmöglichkeiten für einfache Testidentitäten

Der Anbieter des sektoralen IDPs KANN zusätzlich zu einem automatisierbaren Authentisierungsverfahren auch die produktiv verwendeten Authentisierungsverfahren für die Testidentitäten im Zusammenspiel mit seinem Authenticator-Modul bereitstellen. [<=]

A_23154 - KVNRs für einfache Testidentitäten

Der Anbieter des sektoralen IDPs MUSS die KVNRs für seine einfachen Testidentitäten nach Absprache mit der gematik wählen, damit Kollisionen vermieden werden. [<=]

A_23155 - Bereitstellung komplexer Testidentitäten

Der Anbieter des sektoralen IDPs MUSS bei der Bereitstellung komplexer Testidentitäten für alle seinen Testinstanzen unterstützen. Diese Unterstützung kann z. B. in der Einbindung kartenbasierter Testidentitäten einer Kasse oder der gematik oder Test-nPAs bestehen. [<=]

A_23156 - Bereitstellung Authentisierungsmöglichkeiten für komplexe Testidentitäten

Der Anbieter des sektoralen IDPs MUSS die produktiv verwendeten Authentisierungsverfahren für die komplexen Testidentitäten im Zusammenspiel mit seinem Authenticator-Modul bereitstellen. [<=]

A_23413 - Entity Statement vom Federation Master abrufen

Der sektorale IDP MUSS zur Teilnehmerbestätigung anfragender Fachdienste deren Entity Statements vom Federation Master entsprechend [gemSpec_IDP_FedMaster]#AF_10101 einholen. [<=]

A_22662 - Registrierung beim Federation Master durch organisatorischen Prozess

Der Anbieter des sektoralen IDP MUSS seine öffentlichen Schlüssel für die Signatur des selbst signierten Entity Statement über einen vom Federation Master angebotenen organisatorischen Prozess bei diesem bekannt machen. [<=]

A_22643 - Entity Statement des sektoralen IDP

Der sektorale IDP MUSS ein selbst signiertes Entity Statement gemäß [OpenID Connect Federation 1.0#entity-statement] bereitstellen und im Internet verfügbar machen.  Mindestens die in den Tabellen Header Entity Statement des sektoralen IDP und Body Entity Statement des sektoralen IDP in 7.1.4 Detailinformationen zum App-App-Flow genannten Daten und Werte MÜSSEN im Entity Statement enthalten sein.

A_24403 - Signalisierung der Unterstützung von Claims

Der sektorale IDP MUSS in seinem metadata Statement über den Parameter claims_supported signalisieren, welche Claims er unterstützt. [<=]

A_22710 - Vorlaufzeit bei geplantem Schlüsselwechsel

Der Anbieter des sektoralen IDP MUSS Signaturschlüssel im Rahmen eines geplanten Schlüsselwechsels mindestens 24 Stunden vor Verwendung in seinem jwks-Schlüsselsatz veröffentlichen und beim Federation Master über einen organisatorischen Prozess hinterlegen. [<=]

A_22711 - Regelmäßige Erneuerung des Entity Statement des sektoralen IDP

Das Entity Statement des sektoralen IDP MUSS täglich neu ausgestellt werden. [<=]

A_23010 - Maximale Gültigkeitsdauer eines Entity Statement des sektoralen IDP

Die maximale Gültigkeitsdauer eines Entity Statement des sektoralen IDP (Attributwerte iat und exp im Entity Statement) DARF 24 Stunden NICHT überschreiten. [<=]

A_22644 - Entity Statement - Prüfung angebotener URLs

Der sektorale IDP MUSS alle von ihm im Entity Statement angebotenen URLs stündlich auf bloße Erreichbarkeit prüfen. [<=]

A_23132 - Regelmäßige Aktualisierung der Entity Statements bekannter Fachdienste

Der sektorale Identity Provider SOLL die Entity Statements für bekannte Fachdienste nach 2 Stunden erneut herunterladen. [<=]

A_23133 - Maximale Gültigkeitsdauer der Entity Statements bekannter Fachdienste

Der sektorale Identity Provider MUSS die Entity Statements für bekannte Fachdienste nach maximal 24 Stunden verwerfen. [<=]

A_22649 - Anfragen unbekannter Clients

Der Produkttyp sektoraler IDP MUSS Pushed Authorization Request von Clients mit dem http-Statuscode 401 (Unauthorized) ablehnen, wenn diese nicht in der Föderation oder direkt beim sektoralen IDP registriert sind. Ist der Fachdienst dem sektorale IDP nicht bekannt, so stößt dieser intern die automatische Registrierung (https://openid.net/specs/openid-connect-federation-1_0.html#section-10.1.1.1.1) an damit nachfolgende Anfragen angenommen werden können. [<=]

A_22922 - Anfragen veralteter Authenticator Versionen

Der Produkttyp sektoraler IDP MUSS Authorization Request von veralteten Authenticator Versionen ablehnen, wenn diese aus Kompatibilitätsgründen durch die gematik gesperrt wurden. [<=]

A_22650 - automatische Registration von Fachdiensten

Der sektorale IDP MUSS eine automatische Registrierung eines Fachdienstes bei Übermittlung eines Authorization Request mit self_signed_tls_client_auth gemäß [OpenID Connect Federation 1.0 (section-10.1)] durchführen, sofern dieser Dienst nicht bereits am IDP registriert wurde. Nach Abruf des Entity Statement des Fachdienstes beim Fachdienst selbst MUSS der sektorale IDP beim Federation Master dessen Entity Statement zum Fachdienst gemäß [OpenID Connect Federation 1.0 (section-7.1)] abrufen und so dessen Zugehörigkeit zur Föderation bestätigen zu lassen. Anschließend registriert der sektorale IDP den Fachdienst und importiert dessen Schlüssel für die Authentisierung und Verschlüsselung von Token. [<=]

A_22651 - Parameter des Pushed Authorization Request durch den sektoralen IDP

Der sektorale IDP MUSS die Annahme von Pushed Authorization Request gemäß [OAuth 2.0 Pushed Authorization Requests#section-2] unterstützen und den Endpoint für Pushed Authorization Request im Entity Statement des sektoralen IDP pushed_authorization_request_endpoint bekanntgeben.
Der sektorale IDP MUSS mindestens die in der 7.1.4 Detailinformationen zum App-App-Flow Tabelle Parameter Pushed Authorization Request dargestellten Parameter im Pushed Authorization Request des Authorization-Server eines Fachdienstes annehmen. 

A_24404 - Unterstützung von Claims im Authorization Request

Der sektorale IDP MUSS den Parameter claims im Pushed Authorization Request verarbeiten können und dies in seinem metadata Statement über den Parameter claims_parameter_supported signalisieren. [<=]

A_22966-01 - Prüfung eingehender Pushed Authorization Request durch den sektoralen IDP

Prüfung eingehender Pushed Authorization Request durch den sektoralen IDP
Der sektorale IDP MUSS die eingehende Pushed Authorization Request validieren und invalide Request gemäß [OAuth 2.0 Pushed Authorization Requests#section-2.3 ] mit einer Fehlernmeldung quittieren. Die Validierung des eingegangenen Pushed Authorization Request schließt die Prüfung der im Request enthaltenen Werte für redirect_uri, scope und claims gegen die für den Fachdienst zulässigen (d.h. bei der Registrierung gemeldeten) Werte ein.
[<=]

A_22991 - Prüfung des TLS Clientzertifikates am PAR-Endpunkt des sektoralen IDP

Der PAR-Endpunkt des sektoralen IDP MUSS das im Rahmen der self_signed_tls_client_auth übertragene Zertifikat des Fachdienstes wie folgt überprüfen:

• Das Zertifikat ist über das Entity Statement des Fachdienstes zu verifizieren.
• Das Zertifikat ist zeitlich gültig.

A_22992 - Antwort auf einen eingehenden Pushed Authorization Request durch den sektoralen IDP

Der sektorale IDP MUSS auf einen validen Pushed Authorization Request mit einem http-Statuscode 201 gemäß OAuth 2.0 Pushed Authorization Requests (section-2.2) antworten. [<=]

A_22993 - Gültigkeit der vom sektoralen IDP erstellten Request-URI

Die Gültigkeit der vom sektoralen IDP erstellten Request-URI DARF NICHT 90 Sekunden überschreiten. [<=]

A_22312-02 - Einhaltung der Standards bei der Realisierung des Authorization-Endpunkts

Der sektorale Identity Provider MUSS die Schnittstelle Authorization-Endpunkt gemäß [RFC6749 - The OAuth 2.0 Authorization Framework (section-3.1)], [RFC8252 - OAuth 2.0 for Native Apps] und [RFC9126 -  OAuth 2.0 Pushed Authorization Requests (section-4) ] sowie weitere darin festgelegte Standards implementieren. Hierbei MÜSSEN nur im Rahmen der gemSpec_IDP_Sek relevante Aspekte berücksichtigt werden.
[<=]

A_22324 - Verwendung des Attributes "state" durch sektoralen IDP

Der Authorization-Endpunkt des sektoralen Identity Provider MUSS den state-Parameter [RFC6749 # section-10.12] der Anfrage in allen darauf basierenden Responses verwenden. [<=]

A_22325-01 - Übermitteln des "AUTHORIZATION_CODE" an den Sender des Requests

Der sektorale Identity Provider MUSS den AUTHORIZATION_CODE und den state auf demselben Kanal beantworten, auf dem er den Authorization Request empfangen hat.
[<=]

A_22653 - Annahme von "AUTHORIZATION_CODE" und "CODE_VERIFIER"

Der Token-Endpunkt des sektoralen IDP MUSS die vom Authorization-Server eines Fachdienstes übertragenen AUTHORIZATION_CODE und CODE_VERIFIER annehmen. [<=]

A_23007 - Gültigkeit des "AUTHORIZATION_CODE"

Die Gültigkeitsdauer eines AUTHORIZATION_CODE DARF 90 Sekunden NICHT überschreiten. [<=]

A_23162 - Invalidisierung des "AUTHORIZATION_CODE"

Der AUTHORIZATION_CODE MUSS nach einmaliger Verwendung invalidiert werden. [<=]

A_22321 - Prüfung des "CODE_VERIFIER"

Der Token-Endpunkt des sektoralen Identity Provider MUSS die Überprüfung des CODE_VERIFIER gegen die CODE_CHALLENGE mit S256 (Algorithmus nach [RFC7636 # section-4.2]) durchführen. [<=]

A_22654 - Prüfung des TLS Clientzertifikates am Token-Endpunkt des sektoralen IDP

Der Token-Endpunkt des sektoralen IDP MUSS das im Rahmen der self_signed_tls_client_auth übertragene Zertifikat des Fachdienstes wie folgt überprüfen:

• Das Zertifikat ist über das Entity Statement des Fachdienstes zu verifizieren.
• Das Zertifikat ist zeitlich gültig.

A_22323 - Protokollierung der Token-Ausgabe in allen Fällen

Der Token-Endpunkt des sektoralen Identity Provider MUSS im Positivfall die Herausgabe der Token und im Negativfall die Token-Anfrage protokollieren. [<=]

A_22316 - Maximale Gültigkeitsdauer von "ID_TOKEN"

Der sektorale Identity Provider DARF ID_TOKEN mit einer Gültigkeitsdauer von mehr als 300 Sekunden (5 Minuten) NICHT ausstellen. [<=]

A_22706-01 - "ID_TOKEN" des sektoralen IDP

Der sektorale IDP MUSS nach erfolgreicher Prüfung des erhaltenen AUTHORIZATION_CODE dem aufrufenden Authorization-Server des Fachdienstes ein ID_TOKEN gemäß OIDC Standard OpenID Connect Core 1.0 (section-2) mit den angefragten scopes und claims zurückgeben.
[<=]

A_22983 - Signaturverfahren für Signatur des "ID_TOKEN" des sektoralen IDP

Das für die Signatur der ID_TOKEN zu verwendende Verfahren MUSS ECDSA auf Basis der NIST-Kurve P-256 sein. (vergleiche JSON Web Signature (section-3)). [<=]

A_22655-02 - Signatur des "ID_TOKEN" des sektoralen IDP

Der sektorale IDP MUSS die ID_TOKEN unter Verwendung eines privaten Schlüssels, der zu einem direkt unter jwk im Entity Statement stehenden oder unter signed_jwks_uri referenzierten öffentlichen Schlüssel gehört, signieren [OpenID Connect Federation 1.0 (section-4.2)].

Zum öffentlichen Schlüssel des verwendeten Schlüsselpaares MUSS es ein Signaturzertifikat des Typs C.FD.SIG und der technischen Rolle „oid_idpd_sek“ gemäß [gemSpec_Krypt # Abschnitt 3.7] aus der Komponenten-PKI der TI geben, welches im Parameter x5c des ID_TOKEN Headers enthalten ist. [<=]

A_23193-01 - Verschlüsseln der "ID_TOKEN"

Der sektorale IDP MUSS einen Verschlüsselungsschlüssel des Fachdienstes über den use Parameter ("use = enc") aus dessen jwks wählen und mit diesem das ID_TOKEN verschlüsseln. Im JWE-Header des Token referenziert der sektorale IDP über den Parameter kid einen Hinweis auf den verwendeten Verschlüsselungsschlüssel. Als Verschlüsselungsverfahren MUSS hierbei ECDH-ES verwendet werden. [<=]

A_22989-01 - "scopes" und "claims" des sektoralen IDP für Versicherte

Ein sektoraler IDP, welcher die Identitäten für Versicherte verwaltet, MUSS mindestens die folgenden scopes und claims unterstützen:

Tabelle 5: scopes und claims

A_23197 - Nutzung eines pairwise Subject als Pseudonym des Versicherten

Der sektorale IDP MUSS das Attribut "sub" gemäß [OpenID Connect Core 1.0 (sektion-8.1) ] als pairwise Subject Identifiers bilden. Dieses wird als pseudonyme ID des Versicherten verwendet:

• Der Subject Identifier MUSS je Versichertem und Fachdienst fest und eineindeutig sein
• Der Subject Identifier MUSS sich für einen Versicherten gegenüber jedem Fachdienst unterscheiden.

A_22990-01 - Umgang mit fehlenden oder verwehrten Informationen

Ein sektoraler IDP MUSS, wenn ihm der Wert eines scopes nicht vorliegt und es keine Regel für eine Alternativbelegung gibt (siehe z. B. Belegungsregel "birthday" in A_22989) oder ein scope vom Nutzer verwehrt wurde, diesem scope entsprechende claims im ID_TOKEN unterdrücken. Explizit (durch einen Request-Parameter claims) angefragte claims DARF ein IDP NICHT im ID_TOKEN zurück liefern, wenn das claim keinen Wert enthält oder die Nutzer-Zustimmung zur Weitergabe nicht erteilt wurde. [<=]

A_23024 - Definition "gematik-ehealth-loa-substantial"

Der Anbieter des sektoralen IDP MUSS gematik-ehealth-loa-substantial wie folgt interpretieren: 
Der Wert gematik-ehealth-loa-substantial entspricht der Widerstandsfähigkeit des Authentisierungsmittels und Protokolls gegen das Angriffspotential "moderate" nach [ISO18045].
Zertifizierungen, Notifizierung  oder Bestätigungen von Prozessen oder Prozessbestandteilen vergleichbarer Normen und Richtlinien, z. B. nach Verordnung (EU) Nr. 910/2014 in Verbindung mit (EU) 2015/1502 an elektronische Identifizierungsmittel, BSI TR-03107-1 oder vergleichbar, können nachgenutzt werden. [<=]

A_23025 - Definition "gematik-ehealth-loa-high"

Der Anbieter des sektoralen IDP MUSS gematik-ehealth-loa-high wie folgt interpretieren: 
Der Wert gematik-ehealth-loa-high entspricht der Widerstandsfähigkeit des Authentisierungsmittels und Protokolls gegen das Angriffspotential "high" nach [ISO18045].
Zertifizierungen, Notifizierung  oder Bestätigungen von Prozessen oder Prozessbestandteilen vergleichbarer Normen und Richtlinien, z. B. nach Verordnung (EU) Nr. 910/2014 in Verbindung mit (EU) 2015/1502 an elektronische Identifizierungsmittel, BSI TR-03107-1 oder vergleichbar, können nachgenutzt werden. [<=]

A_22987 - Claim "acr" für eine "gematik-ehealth-loa-substantial" Authentisierungsstärke

Der Anbieter des sektoralen IDP MUSS sicherstellen das der claim acr nur auf den Wert gematik-ehealth-loa-substantial gesetzt wird wenn der Nutzer mindestens auf dem Niveau "substanziell" authentisiert wurde (siehe A_23024 - Definition "gematik-ehealth-loa-substantial"). [<=]

A_22988 - Claim "acr" für eine "gematik-ehealth-loa-high" Authentisierungsstärke

Der Anbieter des sektoralen IDP MUSS sicherstellen das der claim acr nur auf den Wert gematik-ehealth-loa-high gesetzt wird wenn der Nutzer auf dem Niveau "hoch" authentisiert wurde (siehe A_23025 - Definition "gematik-ehealth-loa-high"). [<=]

A_22865 - Verpflichtende Verfahren zur Identifikation von Nutzern

Der Anbieter des sektoralen IDP MUSS einen Prozess zur Identifikation von Nutzern mit mindestens diesen Identifikationsverfahren zur Nutzeridentifikation anbieten:

• Identifikation mittels elektronischem Identitätsnachweis (online Ausweisfunktion)
• Identifikation mittelt eGK und PIN

A_22334-01 - Verifikation des Versicherten vor erster Nutzung

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass der Zuordnungsprozess zwischen einer natürlichen Person und den Daten der Attributbestätigenden Stelle eindeutig ist.
[<=]

A_23102 - Weitere Verfahren zur Identifikation von Nutzern

Alle Verfahren zur Identifikation des Nutzers müssen dem Angriffspotential high nach ISO 18045 standhalten. Die Bewertung der Zulässigkeit der Identifikationsverfahren erfolgt in Einzelprüfung durch die gematik.  [<=]

A_22712 - Unterstützung von NFC eGK und PIN

Der Hersteller eines sektoralen IDP MUSS ein Authentifizierungsverfahren über NFC mittels eGK und PIN unterstützen. [<=]

A_22713 - Unterstützung des elektronischen Identitätsnachweis (online-Ausweisfunktion)

Der Hersteller eines sektoralen IDP MUSS ein Authentifizierungsverfahren mittels elektronischem Identitätsnachweis (Online-Ausweisfunktion) unterstützen. [<=]

A_23026 - Entfernen von Authentifizierungsverfahren, welche die Vorgaben nicht mehr erfüllen

Der Anbieter eines sektoralen IDP MUSS sicherstellen, dass Authentifizierungsverfahren entfernt/ausgeschlossen werden, wenn sie das entsprechende Sicherheitsniveau gematik-ehealth-loa-high bzw. gematik-ehealth-loa-substantial nicht mehr erfüllen. [<=]

A_24547 - Anfrage spezifischer Authentisierungsmittel (amr) durch Relying Parties

Ein sektoraler IDP MUSS die Anfrage von Relying Parties zum Einsatz bestimmter Authentisierungsmittel im claims Parameter des Authorization Request durch Verwendung des Claims authentication_method_reference (amr) unterstützen. [<=]

A_25753 - Verfahren zum Erzwingen einer Authentisierung des Nutzers

Der sektorale IDP MUSS mindestens die Verfahren "max_age=0" und "prompt=login" zur Durchsetzung der Benutzerauthentifizierung unterstützen.  Verpflichtende Parameter, die sich daraus ergeben (z.B. auth_time), MÜSSEN gemäß https://openid.net/specs/openid-connect-core-1_0.html berücksichtigt werden. [<=]

A_23129-03 - Identifikation des Authentifizierungsverfahren

Der sektorale Identity Provider MUSS den claim amr im ID_TOKEN entsprechend dem durchgeführten Authentisierungsverfahren nach folgender Tabelle belegen.

Tabelle 6: Codierung der Authentisierungsverfahren

A_25239 - Authentifizierung mit eGK+PIN ohne Prüfung Gerätebindung (Gastzugang)

Der sektorale IDP MUSS über sein Authenticator-Modul die Authentifizierung eines Nutzers mit eGK+PIN ohne Prüfung oder Anlegen einer Gerätebindung unterstützen, wenn eine Relying Party eine Nutzer Authentifizierung urn:telematik:auth:guest:eGK beim sektoralen IDP anfordert. In diesem Fall MUSS der sektorale IDP die Gültigkeit des AUT-Zertifikats der eGK prüfen und die Zertifikatsattribute für die Erstellung des ID_TOKEN verwenden. 

Hinweis 1: Ist der Nutzer bei der Krankenkasse versichert, bei dessen sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP einen Nutzeraccount zu diesem Nutzer anlegen, wenn dieser noch nicht existiert.

Hinweis 2: Ist der Nutzer bei einer anderen Krankenkasse versichert als der, bei deren sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP im ausgestellten ID_TOKEN nur scopes/claims bestätigen, die aus dem Zertifikat der eGK ermittelt, werden können.
[<=]

A_22867 - Signalisierung der Verwendung des Authentisierungsverfahrens "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf

Der sektorale IDP MUSS den claim amr auf den Wert "urn:telematik:auth:mEW" setzen, wenn der Fachdienst eine Authentifizierung des Nutzers auf dem Niveau "gematik-ehealth-loa-high" angefragt hat, der Nutzer jedoch ein Authentisierungsverfahren auf dem Niveau "gematik-ehealth-loa-substantial" verwendet hat. Die Einwilligung des Anwenders zur Nutzung dieses Verfahrens zum Zugriff auf Daten mit hohem Schutzbedarf MUSS vorliegen.  [<=]

A_23103 - Einwilligung zur Verwendung des Authentisierungsverfahrens "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf

Vor der Nutzung von Authentisierungsverfahren mit substantiellem Schutzniveau beim Zugriff auf Daten mit hohem Schutzbedarf nach A_22867 MUSS der sektorale IDP sicherstellen, dass die Einwilligung des Nutzers vollständig freiwillig erfolgt. Dabei müssen alternative Verfahren mit Sicherheitsniveau "gematik-loa-high" hervorgehoben und die Möglichkeit des Widerrufs der Einwilligungserklärung aufgezeigt werden. Der Nutzer muss insbesondere über die Risiken einer Absenkung des Vertrauensniveaus informiert werden und der Verwendung eines Verfahrens mit einem anderen angemessenen Sicherheitsniveau zum Zugriff auf Daten mit hohem Schutzbedarf aktiv zustimmen. [<=]

A_25248 - Protokollierung der Einwilligung zur Verwendung von Authentisierungsverfahren "gematik-ehealth-loa-substantial"

Der sektorale IDP MUSS die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial protokollieren. [<=]

A_22744 - Authenticator auf Zweitgerät

Der Hersteller eines sektoralen IDP MUSS ein technisches Verfahren für den Fall etablieren, dass ein Nutzer das Authenticator-Modul auf einem anderen Gerät betreibt als die Frontend Komponente des  Fachdienstes, welcher eine Authentifizierung beim sektoralen IDP angefragt hat. In diesem Fall MUSS der sektorale IDP für den Auth-Endpunkt ein WebFrontend bieten, welches die weitere Authentisierung über einen Authenticator auf einem anderen Gerät ermöglicht. [<=]

A_22306-01 - Information des Nutzers bei fehlender Installation des gewählten Authenticator-Moduls

Der Hersteller eines sektoralen IDP MUSS ein technisches Verfahren für den Fall etablieren, dass ein Nutzer das Authenticator-Modul nicht installiert hat. In diesem Fall MUSS der sektorale IDP für den Auth-Endpunkt ein WebFrontend anbieten und dort darstellen, aus welcher Quelle das jeweilige Authenticator-Modul des sektoralen Identity Provider zu beziehen ist, auf welchen Geräten/Plattformen es installiert werden kann und welche Voraussetzungen für die Verwendung zur Authentifizierung zu erfüllen sind (z. B. erforderliche Registrierungsprozeduren beim Anbieter des sektoralen Identity Provider). [<=]

A_22257 - Operationsaufruf erfordert erfolgreiche Authentifizierung

Der sektorale Identity Provider MUSS sicherstellen, dass Authorization Request nur nach vorheriger erfolgreicher Authentifikation des Nutzers mit einem AUTHORIZATION_CODE beantwortet werden. [<=]

A_22235 - Information des Versicherten über Änderungen an Authentifizierungsfaktoren

Der Anbieter des sektoralen Identity Provider MUSS den Versicherten über Änderungen an Authentifizierungsfaktoren informieren.
Die Information des Versicherten kann dabei auch über die Attributbestätigende Stelle erfolgen, welche den Anbieter des sektoralen Identity Provider mit der Erstellung des elektronischen Identifizierungsmittels beauftragt hat. [<=]

A_22236-01 - Auskunft an Versicherten

Der Anbieter des sektoralen Identity Provider MUSS dem Versicherten auf dessen Verlangen Auskunft geben über:

• erfolgte Zugriffe auf das elektronische Authentisierungsmittel des Versicherten
• Änderungen der Authentifizierungsfaktoren des Versicherten
• Einwilligungen zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial

A_23623 - Wahlfreiheit des Authentisierungsverfahren für TI-Anwendungen

Wenn der sektorale IDP neben dem elektronischen Identitätsnachweis (Online-Ausweisfunktion) und eGK+PIN weitere Authentisierungsverfahren auf dem Niveau gematik-ehealth-loa-high anbietet, so MUSS dem Nutzer die Möglichkeit gegeben werden auszuwählen, welche Verfahren (Online-Ausweisfunktion, eGK+PIN, weitere) für die Authentisierung bei TI-Fachanwendungen verwendet werden dürfen.
Dabei MUSS der sektorale IDP eine beliebige Auswahl (mindestens einer) der bereitgestellten Authentisierungsmethoden  ermöglichen. Der Nutzer MUSS die Möglichkeit haben diese Auswahl zu ändern sowie ein bevorzugtes Verfahren festzulegen. [<=]

A_22750-01 - Gerätebindung und Authentisierung für "gematik-ehealth-loa-high" und "gematik-ehealth-loa-substantial"

Abhängig von der Geräteausstattung des Nutzers ist eine Gerätebindung für einen festgelegten Zeitraum ohne Erneuerung gültig. Der Anbieter des sektoralen IDP MUSS, wenn er eine Gerätebindung im Rahmen eines Authentisierungsverfahren nutzt, die Zeitrahmen der Gültigkeit für die Gerätebindung gemäß Tabelle "Übersicht Gerätebindung" berücksichtigen.
Beim Zugriff auf Daten mit hohem Schutzbedarf gelten die Zeiträume der maximalen Gerätebindung gematik-ehealth-loa-high in der Tabelle. Nach Einwilligung des Nutzers gemäß A_23103* gelten beim Zugriff auf Daten mit hohem Schutzbedarf, unter Verwendung von Authentisierungsverfahrens gematik-ehealth-loa-substantial die Zeiträume der maximalen Gerätebindung gematik-ehealth-loa-substantial in Tabelle "Übersicht Gerätebindung".
Die Gerätebindung MUSS durch den Nutzer nach Ablauf dieser Frist dementsprechend erneuert werden.
Der Anbieter des sektoralen IDP MUSS mit den zur Verfügung stehenden Plattformmechanismen, einen kryptographischen Nachweis der Gerätebindung auf dem Endgerät erzeugen und auf Serverseite prüfen (z.B. Android: Key & ID Attestation; iOS: DCAppAttestService).
Die Gerätebindung kann:

1. durch Identifikation, welche dem Niveau gematik-ehealth-loa-high entspricht oder  
2. mit einer 2FA, welche dem Niveau gematik-ehealth-loa-high entspricht,

Tabelle 7: Übersicht Gerätebindung

A_23700 - Verwendung von PIN und Passwort als Faktor zur Nutzerauthentifizierung

Ein sektoraler IDP KANN als Wissensfaktor für Android- und iOS-Geräte die vom Nutzer vergebene System-PIN oder das System-Passwort verwenden. [<=]

A_25138-01 - Erneuerung der Gerätebindung für "gematik-ehealth-loa-high"

Nach Ablauf der Gültigkeitsdauer einer Gerätebindung DARF die bestehende Gerätebindung NICHT als Authentisierungsfaktor für die Erneuerung der Gerätebindung für gematik-ehealth-loa-high verwendet werden.
[<=]

A_23699 - Erstellung oder Erneuerung einer Gerätebindung an eine Nutzeridentität

Der Hersteller des sektoralen IDP MUSS zur Erstellung oder Erneuerung der Gerätebindung eine Identifizierung oder Authentifizierung des Nutzers auf dem Vertrauensniveau "gematik-ehealth-loa-high" durchführen. Die Nutzung einer bestehenden Gerätebindung zur Erneuerung einer Gerätebindung an eine Nutzeridentität ist gemäß A_25138 ausgeschlossen. [<=]

A_25969 - Keine Nutzung einer Gerätebindung zur Einrichtung einer Gerätebindung

Eine Gerätebindung DARF NICHT mittels einer bestehenden Gerätebindung neu eingerichtet werden. [<=]

A_23701 - Verwendung von Biometrie als Faktor zur Nutzerauthentifizierung

Der Anbieter der sektoralen TI MUSS die in der Tabelle "Biometrie" aufgeführten Einschränkungen für die Nutzung biometrischer Sensoren zur Authentifizierung des Nutzers berücksichtigen. Für die Nutzung eines biometrischen Faktors MUSS, wenn damit eine Herabstufung des Vertrauensniveaus verbunden ist, die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf (A_23103) vorliegen.

Tabelle 8: Biometrie

A_23207-01 - Single-Sign-On (SSO) als Authentifizierungsverfahren

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS im claim acr das Niveau beauskunften, welcher dem der vorhergehenden Authentisierung entspricht. Der claim amr MUSS auf den Wert urn:telematik:auth:sso gemäß der Tabelle "Codierung der Authentisierungsverfahren" gesetzt werden. [<=]

A_23208-01 - Zustimmung des Nutzer für SSO

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor der Aktivierung eines Single-Sign-On (SSO) nach A_23207 sicherstellen, dass die Einwilligung des Nutzers hierzu insbesondere aufgeklärt, vollständig freiwillig, unter Hervorhebung sichererer Verfahren und widerrufbar erfolgt. Der Nutzer MUSS über die Risiken des SSO ausreichend aufgeklärt werden und der Verwendung für jeden einzelnen Fachdienst aktiv zustimmen.
[<=]

A_24721-01 - Ausstellen einer SessionID zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO nach der ersten erfolgreichen Nutzerauthentisierung eine SessionID zum laufenden Anwendungskontext generieren und dem Authenticator-Modul des Anwendungskontextes übertragen. Der Hersteller von sektoralen IDP MUSS sicherstellen, dass eine zu einem Anwendungskontext ausgestellte SessionID ausschließlich für diesen verwendet werden kann und nach dem Schließen des Anwendungskontext gelöscht wird. [<=]

A_24725-01 - Prüfung der SessionID zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO jede Nutzerauthentisierung ohne Nutzerinteraktion die Gültigkeit, der vom Authenticator-Modul übertragenen SessionID überprüfen indem:

• die Signatur der SessionID mit dem zum Nutzer und zur SessionID gespeicherten public Key validiert wird,
• die SessionID mit der zum Nutzer gespeicherten SessionID verglichen wird,
• der Gültigkeitszeitraum der SessionID überprüft wird.

A_23212-02 - Gültigkeitsdauer einer SessionID

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS sicherstellen, dass die vom sektoralen IDP zu einem Anwendungskontext ausgestellte SessionID ungültig wird und gelöscht werden muss, wenn:

• der Anwendungskontext, zu dem die SessionID erstellt wurde, beendet wurde
• der Nutzer bei offenem Anwendungskontext mindestens 10 Minuten inaktiv war
• die SessionID die maximale Gültigkeitsdauer von 1h überschreitet