Fragen & Antworten (FAQ)

Die Spezifikationen zur TI-Föderation können online eingesehen werden. Die Links zu den relevanten Spezifikationen sind auf der Einstiegsseite der IDP Wissensdatenbank unter "Aktuelle Spezifikation online lesen" aufgeführt.  Die Spezifikation der sektoralen IDPs ist vorerst begrenzt auf die Authentifizierung von Versicherten. Die Anforderungen an sektorale IDPs für Leistungserbringer und Leistungserbringerinstitutionen sind derzeit in Vorbereitung.

Zusätzliche Dokumentationen zum Identity Management finden Sie auf den weiteren Seiten der IDP Wissensdatenbank.

Für die erstmalige eindeutige Identifikation kann ein Diensteanbieter  durch die Online-Ausweisfunktion (eID-Funktion) die folgend aufgeführten Attribute des Ausweisinhabers ausgelesen werden:

• Familienname
• Vornamen
• Geburtsname
• Doktorgrad
• Tag der Geburt
• Ort der Geburt
• Anschrift

Diese Daten können verwendet werden, um den Anwender eindeutig einem Datensatz im Bestand des IDP/des Kostenträgers zuzuordnen.

Für die folgenden Authentisierungen reicht es aus, das dienste- und kartenspezifische Kennzeichen (wie z.B. die Personalausweisnummer) zu verwenden, mit welchem der Anwender eindeutig wiedererkannt werden kann. Zu beachten ist, dass sich das dienste- und kartenspezifische Kennzeichen nach Neuausstellung ändert, die Zuordnung also erneut erfolgen muss.

Konkrete Anforderungen und eine Dokumentation für einen einzelnen verpflichtenden Weg gibt es keine. Die gematik hat sich bewusst entschieden den Herstellern hier Freiheiten zu lassen.

Orientieren kann man sich natürlich an dem Prozess wie er beim IDP-Dienst für diese Funktionalität umgesetzt ist. Dabei wird eine an das Authenticator Modul gesendete Challenge mittels eGK signiert und diese Antwort (Signatur und verschlüsseltes Zertifikat) dann geprüft auf zeitliche und kryptographische Gültigkeit sowie das verwendete Zertifikat mittels OCSP Anfrage beim TSP validiert.

Die relevanten Anforderung dazu sind in gemSpec_IDP-Dienst (A_20521*, A_20314*, A_20699*, A_20951*, A_22328*, A_22290*, A_20465*) und in gemSpec_IDP_Frontend (A_20525*, A_19908*, A_20700*, A_20526*) formuliert. Die Spezifikationsdokumente können aus dem Fachportal runtergeladen werden.

Hier wären aber explizit auch andere Wege der Gültigkeitsprüfung gegen die Systeme der Krankenkasse möglich und sinnvoll. So wäre es nicht notwendig das Zertifikat der eGK verschlüsselt zum sektoralen IDP zu übertragen, wenn dieser die Informationen zum Nutzer in einem eigenen Datenbestand vorhalten und im Backend mit der Kasse abgleichen. Es kann also durchaus ausreichen die Challenge zu signieren und den öffentlichen Schlüssel zu übertragen mit welchem der IDP alle weiteren Daten in seiner Datenbank findet.

Im Rahmen der mittels der App2App-Link-kommunizierten Parameter können auch OAuth konforme Error-Codes und Error-Descriptions als Parameter vom Authenticator-Modul an das Frontend übermittelt werden. Im nächsten überarbeiteten Release der Spezifikation sollen Aspekte zur Fehlerbehandlung ergänzt werden, damit für das Anwendungsfrontend bzw. den aufrufenden Fachdienst deutlich wird, welche Fehlercodes zu erwarten sind und für den sektoralen IDP klargestellt wird, dass diese vom Authenticator-Modul weitergereicht werden müssen. So kann eine Anwendung entsprechend reagieren und ggf. eine erneute Authentisierung anstoßen oder den Nutzer über Probleme informieren.

Die Anforderungen A_25138* (Erneuerung der Gerätebindung für "gematik-ehealth-loa-high") und A_23699* (Erstellung oder Erneuerung einer Gerätebindung an eine Nutzeridentität) schließen aus, dass die bestehende Gerätebindung als Authentisierungsfaktor für die Erneuerung einer Gerätebindung für gematik-ehealth-loa-high verwendet werden darf. Der Schlüsseltausch ohne Nutzerinteraktion ist damit nicht möglich.

Die anzubietenden Identifikationsverfahren und  Authentisierungsverfahren "eGK mit PIN" und "Online Ausweisfunktion" müssen unabhängig vom Anlegen eines Benutzeraccounts möglich sein.

Benutzeraccounts können/müssen eingerichtet werden, um ein eindeutiges Mapping der "Online Ausweisfunktion" auf einen Versicherten zu vollziehen. Diese haben allerdings nicht zwingend ein gesondertes Authentisierungsverfahren, sondern müssen auf Wunsch des Nutzers die Anmeldung an den TI-Fachdiensten lediglich über das gewählte Authentisierungsmittel (eID/eGK) beschränken.

Werden neben den geforderten Verfahren "elektronischer Identitätsnachweis" (A_22713) bzw. "eGK+PIN" (A_22712) verpflichtend weitere Authentifizierungsverfahren für einen Nutzer eingerichtet, so muss dem Nutzer die Möglichkeit gegeben werden auszuwählen, welche Verfahren für die Authentisierung bei TI-Fachanwendungen verwendet werden dürfen. Dies wird mit der Anforderung A_23623 klargestellt.

Die Zertifikate müssen von einer CA bezogen werden, welche die Ausstellung der Zertifikate in einem Certificate Transparency Log protokolliert. Diese Log-Einträge müssen geprüft werden. Für die Prüfung von Logeinträgen zu Domain gibt es eine Reihe von CT-Anbietern. Die gematik schreibt kein bestimmtes CT vor. Wenn die CA ein solches präferiert, so kann das gerne verwendet werden.

Es ist nach Spezifikationslage zulässig, dass der IDP einen anderen Schlüssel zur Signatur des JWT, welches unter signed_jwks_uri abgerufen wird, verwendet, als zur Signatur des Entity Statements. Der Schlüssel muss dann über das Entity Statement im Claim jwks auf Root Ebene transportiert werden (also nicht als Metadatum unter openid_provider).

Dieser Schlüssel muss nicht über einen organisatorischen Prozess am Federation Master registriert werden. Seine Verwaltung obliegt allein dem sektoralen IDP.

• Ein Identifizierungsvorgang mit einem entsprechenden Ausweisdokument (nPA, eGK) ist möglich bis einschließlich zum letzten Tag der Gültigkeit des Ausweis-Dokuments.
• Der Zeitraum der Gültigkeit der Identifizierung (abhängig von der Geräteklasse, z.B. sechs Monate) ist nicht abhängig von der noch verbleibenden Gültigkeit des Ausweisdokuments zum Zeitpunkt der Identifizierung.
• Ein Anmeldevorgang (Authentisierung) mit einem entsprechenden Ausweisdokument (nPA, eGK) ist möglich bis einschließlich zum letzten Tag der Gültigkeit des Ausweis-Dokuments.

Aktuell werden über das Identifikationsverfahren "Persönliche Identifikation in der Geschäftsstelle der Krankenkasse" Fälle abgedeckt, für die es derzeit keine Alternativen gibt (Kinder, bevollmächtigte Vertreter). 

Wir als gematik gehen davon aus, dass das Verfahren "Persönliche Identifikation in der Geschäftsstelle der Krankenkasse" bis zu einer möglichen Konkretisierung der Rahmenbedingungen ein zulässiges Identifikationsverfahren sowohl für die PIN-Herausgabe wie auch die Gesundheits-ID bleibt.

Es ist für einen IDP auch zulässig, nach einer fehlgeschlagenen Registrierung weiterhin den HTTP-Fehlercode 401 zu liefern, da die TLS-Aushandlung ohne vertrauenswürdige Schlüssel fehlschlägt. Fehler gemäß OIDC Federation Standard kommen erst innerhalb der TLS-Verbindung zum Tragen. Dies ist für den aufrufenden Fachdienst nicht optimal, aber dieser kann über das ITSM der TI eine Problemlösung veranlassen.

Der Fachdienst kann selbst signierte (self-signed) Zertifikate erstellen oder TLS-Client-Zertifikate aus einer CA beziehen.  Aus einer CA bezogene Zertifikate werden durch den sektoralen IDP nicht gegen einen TSP geprüft. Es wird lediglich das konkrete Zertifikat gegen die validen Zertifikate aus dem Entity-Statement des Fachdienstes abgeglichen.

Nein. Eine Nachweis für die Erzeugung von Schlüsseln im Rahmen der Gerätebindung (siehe dazu Anforderung A_22750) gemäß GS-A_4367 / GS-A_4368 ist nicht notwendig.

Die Vorgaben aus GS-A_4367 gelten nicht für das Mobile Endgerät sondern nur für Schlüssel der Serverkomponenten innerhalb der VAU. Der Sicherheit der Schlüssel auf dem Mobilgerät wird über die Vorgaben zum Schlüsselwechsel Rechnung getragen.

Der Anwendungsbereich erstreckt sich ausschließlich auf Schlüsselmaterial, welches im Rahmen der Kommunikation zwischen dem sektoralem IDP und anderen Teilnehmern der Föderation Anwendung findet:

• Signaturen von  (ID-)Token, Entity Statement
• TLS-Verbindungen zu Teilnehmern der TI-Föderation →  TLS-Clientschlüssel

Schlüsselmaterial hinsichtlich der Kommunikation zwischen Komponenten innerhalb des sektoralen IDP liegt nicht im Anwendungsbereich dieser Anforderung.

Schlüsselmaterial betreffend des Authentifizierungsmechanismus zur Authentifizierung des Nutzers liegt nicht im Anwendungsbereich dieser Anforderung (siehe dazu die Anforderungen A_23025 und A_23024).   

Der Anwendungsbereich der  Anforderung erstreckt sich nicht auf die Schlüsselerzeugung bzw. dafür genutzte Zufallsgeneratoren. Anforderungen an die Schlüsselerzeugung/Zufallsgeneratoren werden von GS-A_4367 – Zufallszahlengenerator,  GS-A_4368 – Schlüsselerzeugung erfasst.

Mehraugenprinzip:

Die gematik wird keine aktive Beteiligung im Quorum (Mehraugenprinzip) haben. Ein Quorum kann z. B. durch den Anbieter des sektoralen IDP und eine Krankenkasse als Auftraggeber gebildet werden. Sollte der Anbieter des sektoralen IDP keine unabhängige Stelle finden, mit der ein Quorum gebildet werden kann, bietet die gematik allerdings an, diese Rolle zu übernehmen.

Remote-Teilnahme der gematik:

Die gematik wird sich bei der Umsetzung vom Mehraugenprinzip (Quorum) in der Regel nicht aktiv beteiligen. Die gematik behält sich jedoch das Recht vor, auf Anfrage über eine Konferenzschaltung die Umsetzung des Prozesses zu beobachten. Für die Sicherstellung der Anforderungserfüllung (Mehraugenprinzip und Remote-Teilnahme) ist eine Prozessdokumentation der Umsetzung ausreichend.

Gemeint ist eine nicht gematik-spezifische Prüfung ohne TI-Komponenten und ohne OCSP. Die Formulierung dient der Abgrenzung vom bisherigen Vorgehen. Beim Einsatz von TLS-Bibliotheken, wie z. B. OpenSSL, besteht keine Notwendigkeit, bis auf eine Root zu prüfen oder bestimmte Zertifikatsinhalte zu validieren. 

Hinsichtlich der TLS-Zertifikate gilt: Es sind keine EV-Zertifikate notwendig. Wichtig ist, dass die Zertifikatsherausgabe gemäß CAB-Forum erfolgt, und dass die CA Certificate Transparency unterstützt wird.

Die IDP können Verfahren zur Nutzerauthentifizierung z.B.  für die Administration des Nutzer-Accounts durch den Nutzer einrichten. Durch die Anforderung soll der Nutzer die Möglichkeit haben, solche Verfahren auch nur z.B. zu Administrationszwecken zu verwenden und damit nicht für den Zugriff auf TI-Anwendungen (E-Rezept) zu erlauben.

Die Anforderung hat nicht das Ziel, dass der Nutzer ein bevorzugtes Authentifizierungsverfahren festlegen darf, sondern dass der Nutzer die Liste der vom sektoralen IDP angeboten Verfahren für TI-Anwendungen beschränken kann. Damit soll verhindert werden, dass ein verpflichtend eingerichtetes alternatives Verfahren immer auch den Zugriff auf TI-Anwendungen gewährt, ohne dass der Nutzer eine Wahl hat.

Für die Festlegung muss der Nutzer nicht unbedingt die Verfahren im Einzelnen selbst bewerten können. Dem Nutzer muss lediglich die Liste der vom IDP unterstützen Authentifizierungsverfahren angezeigt werden, die zur Nutzerauthentifizierung für TI-Anwendungen zugelassen sind. Der Nutzer kann wählen (oder abwählen), welche dieser Verfahren zur Authentisierung für TI-Anwendungen benutzt werden dürfen.

Es ist richtig, dass die Nutzerführung für den Fall, dass kein Anwendungsfall bei Abwahl einzelner scopes ausführbar ist, unpraktikabel ist. 

Die Anforderung A_22939* wurde dahingehen präzisiert, dass zwingend notwendige claims im Request (standardkonform) als "essential claims" ausgewiesen werden. Ein zusätzlicher Hinweis zur Anforderung bietet zusätzliche Möglichkeiten im Umgang mit zwingend notwendigen scopes:

"Handelt es sich um eine dem sektoralen IDP bekannte Anwendung (z.B. durch direkte Registrierung eines Kassendienstes im Rahmen der A_23044) ist es zulässig dem Nutzer nur das Annehmen/Ablehnen aller geforderten scopes anzubieten."

Die Liste der zulässigen Identifikationsverfahren  wird von der gematik gepflegt. Die aktuelle Version "Festlegung der zulässigen Identifikationsverfahren" steht im Fachportal der gematik unter  https://fachportal.gematik.de/schnelleinstieg/smartcards-und-identitaeten-in-der-ti/identitaeten zum Download bereit.

Die Intention der Anforderung A_19041 war sicherzustellen, dass der Nutzer organisatorisch in den Prozess zum Erzeugen einer al.vi beim Signaturdienst einwilligt. Dies passierte im Rahmen der Identifikation des Nutzers, welche in der Regel an die Krankenkasse als Kartenherausgeber ausgelagert wurde.

Nachdem nun die Identifikation und Authentisierung der Nutzer vom Signaturdienst auf den sektoralen IDP verlagert worden sind, wurde die Anforderung an die Authentisierung gekoppelt, was die erste Interaktion des SigD mit dem Nutzer darstellt.

Dies sollte jedoch in keiner Weise die Prozesse verkomplizieren, sondern lediglich die vorherigen Festlegungen widerspiegeln. Daher ist es - abweichend von der Formulierung der Anforderung A_19041-01 - zulässig, weiterhin die Zustimmung des Nutzers zur Verwendung des SigD im Kontakt mit der Krankenkasse bzw. dem sektoralen IDP einzuholen. Der Kartenherausgeber kann dies durch das Auslösen der P_Create_Identity-Operation und initiale Bereitstellen der für den Zertifikatsabruf notwendigen Attribute signalisieren. Analog ist die Krankenkasse als Kartenherausgeber ebenfalls der Ansprechpartner des Versicherten für die Sperrung von Zertifikaten.

Eine konkrete Vorgabe zur Aufbewahrungsfrist gibt es seitens gematik nicht. Mit Interpretation der zu protokollierenden Daten als "Protokolldaten" könnte man an §76 BDSG  orientieren. Unsere Empfehlung ist daher eine dann Aufbewahrungsfrist von 1-2 Jahren.

Die Verbindung zwischen Authenticator-Modul und sektoralem IDP ist von der genannte Anforderung nicht betroffen. Das Authenticator-Modul ist keine getrennte Komponente für welche Interoperabilitätsvorgaben greifen.  Für Verbindungen zwischen Authenticator-Modul und sektoralem IDP gilt konkret:

A_18986 - Fachdienst-interne TLS-Verbindungen

Alle Produkttypen, die Übertragungen mittels TLS durchführen, die nur innerhalb ihres Produkttypen verlaufen (bspw. ePA-Aktensystem interne TLS-Verbindungen zwischen dem Zugangsgateway und der Komponente Authentisierung), KÖNNEN für diese TLS-Verbindungen neben den in GS-A_4384-* und ggf. A_17124-* festgelegten TLS-Vorgaben ebenfalls alle weiteren in [TR-02102-2] empfohlenen TLS-Versionen und TLS-Ciphersuiten mit den jeweiligen in [TR-02102-2] dafür aufgeführten Domainparametern (Kurven, Schlüssellängen etc.) verwenden.

Sofern serverseitig gewährleistet ist, dass nur Verbindungen unter Verwendung zulässiger Ciphersuiten aufgebaut werden und sofern Mechanismen zum Schutz vor MiM-Angriffen auf Seite des Clients etabliert sind, ist es zulässig, wenn dieser auch weitere Ciphersuiten unterstützen würde.

Zumindest für Android Version >= 10 kann die Passwortkomplexität über die API geprüft werden.

Mittels DevicePolicyManager.getPasswordComplexity() bekommt man eine ungefähre Einschätzung zur Komplexität des vom Nutzer vergebenen System-Lock (System-PIN/Passwort/Muster):

• • PASSWORD_COMPLEXITY_NONE --> kein Passwort
  • PASSWORD_COMPLEXITY_LOW --> Muster oder PIN mit Wiederholungen (z.B. 4444) bzw. geordneter Sequenze (z.B. 1234, 2467, ...)
  • PASSWORD_COMPLEXITY_MEDIUM --> PIN ohne Wiederholungen oder geordnete Sequenzen mit min. 4 Ziffern oder Passwort mit min. 4 Zeichen
  • PASSWORD_COMPLEXITY_HIGH --> PIN ohne Wiederholungen oder geordnete Sequenzen mit min. 8 Ziffern oder Passwort mit min. 6 Zeichen

Für die Nutzung der API muss im Manifest die Berechtigung android.permission.REQUEST_PASSWORD_COMPLEXITY gesetzt sein

Für den Abruf der Passwortkomplexität werden aktuell keine Device Admin Rechte benötigt. Die API liefert allerdings nur eine Information zum Ist-Stand. Veränderungen des System-Locks durch den Nutzer werden nicht automatisch gemeldet und sollten ggf. durch einen periodischen Abruf der API erfolgen.

Achtung: Die Abfrage erfolgt in der Software und könnte durch App- oder Systemmanipulation falsche Werte zurückmelden. Deshalb sollten weitere Maßnahmen zur Sicherstellung der App- / Systemintegrität implementiert werden.

Die derzeit veröffentlichte Spezifikation basiert auf OpenID Connect Federation 1.0 - draft 21.

OpenID Connect Federation 1.0 - draft 29 ist im Kapitel 4.2 präziser hinsichtlich der möglichen Parameter für Relying Party und verweist zusätzlich auf IANA.OAuth.Parameters].

• OpenID Connect Federation 1.0 - draft 21

All parameters defined in Section 2 of OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration are allowed in a metadata statement.

In addition, the parameters defined in Section 4 for OpenID Connect and OAuth2 entities and the following are added ...

• OpenID Connect Federation 1.0 - draft 29

All parameters defined in Section 2 of OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration and Section 4.1 are applicable, as well as additional parameters registered in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters.

Das in der „Tabelle 24: Body des Entity Statement des Fachdienstes“ genannte Beispiel muss dem Format "scope1 scope2 scope3" entsprechen. (String mit durch Leerzeichen getrennten Bezeichnungen ohne Klammern.)

Wir werden bei der nächsten Spezifikationsanpassung unsere Beispiele entsprechend anpassen und ggf. zusätzlich auf die referenzierten Standards verweisen.

Um das Pseudonym eines Versicherten zu erhalten, muss der Fachdienst im Pushed Authorization Request den scope "openid" anfordern. Nach erfolgreicher Nutzerauthentisierung ist im vom sektoralen IDP ausgestellten ID-Token der claim "sub" mit einer pseudonymen ID des Versicherten gefüllt. Das Pseudonym muss spezifisch je Nutzer, Fachdienst und IDP sein. Damit das erreicht wird, muss ein Fachdienst die pseudonyme ID des Versicherten in Kombination mit dem iss des ausstellenden IDP verwenden.

(siehe Anforderung A_23036 und A_23035)

Der scope "openid" ist immer Bestandteil der Anfrage eines Fachdienstes, deshalb wird jeder Fachdienst auch immer mindestens auf diesen scope registriert.

Damit ein Fachdienst überhaupt die KVNR eines Versicherten im vom sektoralen IDP ausgestellten ID-Token erhalten darf, muss dieser beim Federation Master für den scope "urn:telematik:versicherter" registriert sein.

Der Fachdienst muss nun im Pushed Authorization Request  an den sektoralen IDP den scope "urn:telematik:versicherter" anfordern. Dieser scope enthält u.a. den claim "urn:telematik:claims:id". Im vom sektoralen IDP ausgestellten ID-Token ist der Wert des claims mit der KVNR des Versicherten belegt.

GS-A_5542 greift immer dann wenn die TLS Verbindung nicht etabliert werden konnte. Zu diesem Zeitpunkt besteht noch keine HTTP Verbindung.

Es hängt davon ab, wie restriktiv der Server, welcher das Clientzertifikat anfordert, implementiert oder konfiguriert ist. Das bedeutet, dass ein Server es akzeptieren kann, wenn er kein Clientzertifikat erhält. Der Verbindungsaufbau wird dann nicht zwangsläufig abgebrochen. In diesem Fall ist der Verbindungsaufbau (nur) TLS. Dann kommt es zum Datenaustausch auf Anwendungsebene. In diesem Fall kann der sektorale IDP kann entsprechend RFC8705 ein HTTP-Error werfen. 

Andernfalls bricht der Server den TLS-Aufbau ab und muss nach GS-A_5542 mit einem "fatal Allert" reagieren.

Diese Anforderung einer bereits etablierten TLS-Verbindung wird durch RFC 8705 Sektion-2 klar formuliert:

"In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server MUST have been established or re-established with mutual-TLS X.509 certificate authentication (i.e., the client Certificate and CertificateVerify messages are sent during the TLS handshake)."

War der TLS-handshake erfolgreich, kann der sektorale IDP die Konfiguration des Clients aus dessen Entity Statement gegen das Zertifikat aus dem TLS-handshake prüfen.

Wenn der TLS-Aufbau funktioniert hat aber dieses Zertifikat dann auf Anwendungsebene (Open-ID) nicht vorhanden ist oder als nicht vertrauenswürdig für diese Client-ID erkannt wird, dann muss der sektorale IDP den Fachdienst als "unbekannten Client" behandeln. In diesem Fall gilt 

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.

Diese Anforderung entspricht der Regelung im Standard   RFC 8705 und RFC6749 Section-5.2 "invalid_client".

Prinzipiell ist ihre Anmerkung korrekt.

Derzeit ist die Situation jedoch so, dass ein SSO derzeit nur im Kontext ePA-FdV ("auf Anwendungsebene") erlaubt ist. Da das ePA-FdV 1:1 einem sektoralen IDP zuordenbar und die Umsetzung aktuell kassenspezifisch (bzw. anbieterspezifisch) ist, gibt es hier noch keine weiteren Festlegung sondern derzeit nur eine Umsetzungsempfehlung. Die Umsetzungsempfehlung bezieht sich eben auf  RFC9396 und die Verwendung von authorization_details. Wir arbeiten weiter an SSO-Lösungen, welche über die Einschränkung "auf Anwendungsebene" hinaus gehen. Diese sollten sowohl mit dem BSI als auch mit den Kassen und Anbietern von sekt. IDPs abgestimmt sein.

Wenn die Lösung letztlich auf RFC9396 und authorization_details  aufbaut, können wir regulatorisch diese Parameter detaillieren. Allerdings macht es Sinn, die authorization_details schon so zu beschreiben, wie sie später für alle IDPs normativ umzusetzen sind um Mehrfachentwicklung zu vermeiden. Alle IDP-Hersteller sollten die Vorgaben berücksichtigen, da diese im später normativ für alle sektoralen IDPs gelten werden. Zur Festlegung der "authorization_details" für das SSO ist die gematik in Abstimmung mit den Herstellern der sekt. IDPs.

Nach Veröffentlichung des gemSpec_IDP_Sek_V2.4.0_Aend_RC kam es zu Rückfragen bezüglich der zugeordneten Prüfverfahren. Nach interner Prüfung und Rückfragen bei Gutachtern wurde die Zuordnung der Prüfverfahren korrigiert.

Die Anforderung A_23103 beschreibt das Einholen der Zustimmung (consent) vom Nutzer, dass dieser einen Zugriff einer Fachanwendung auf seine Gesundheitsdaten auch erteilen kann, indem er auf dem Vertrauensniveau "gematik-ehealth-loa-substantial" authentifiziert. Der Zugriff einer Fachanwendung auf Gesundheitsdaten erfordert eigentlich eine Authentisierung auf dem Vertrauensniveau "gematik-ehealth-loa-high". Die Zustimmung erlaubt dem Nutzer z.B. eine Authentisierung mit System-PIN für 12 statt 6 Monate für ein Gerät mit Hardware Keystore. Diese Zustimmung kann einmalig (je account) ausgesprochen werden. Die Auswirkungen auf die Zeiten der Gerätebindung ist dann abhängig von der Geräteklasse und vom Zeitpunkt der letzten Identifizierung bzw. der Herstellung der Gerätebindung.

Diese Zustimmung ist erst einmal unabhängig von jeglichen Anforderungen hinsichtlich der Nutzung von Biometrie.

Möchte ein Nutzer Biometrie verwenden, so gelten die Regeln nach Tabelle "Biometrie".

Für eine Authentisierung auf dem Vertrauensniveau "gematik-ehealth-loa-high" müssen die Biometriesensoren dem entsprechenden Vertrauensniveau hoch nach TR-03107-1 / TR-3166) genügen. Aktuell gibt es keine Biometriesensoren auf dem Markt, welche diese Anforderungen erfüllen.

Hat der Nutzer aber bereits zugestimmt, dass er auch Verfahren zur Authentisierung nutzen kann, die dem Vertrauensniveau "gematik-ehealth-loa-substantial" genügen (A_23103), dann kann er Geräte mit Biometriesensoren nutzen, die dem Vertrauensniveau substantiell nach TR-03107-1 / TR-3166) genügen. Aktuell steht den Nutzern dafür nur Face-ID auf iOS Geräten zur Verfügung.

Da alle weiteren auf dem Markt befindlichen Geräte auch diese Anforderungen nicht erfüllen, muss der Nutzer in diesen Fällen über die Risiken bei der Verwendung aufgeklärt werden und explizit zustimmen, wenn er trotz Warnung die Biometrie dieser Geräte für seine Authentisierung nutzen möchte. Die Ausstattung mit Biometriesensoren ist gerätespezifisch. Die Einschränkungen der Tabelle "Biometrie" müssen berücksichtigt werden. Die Einwilligung zur Nutzung von Biometrie muss deshalb je Gerät erfolgen. Die Einwilligung zur Nutzung von Biometrie darf nicht direkt mit der Zustimmung zur Nutzung von Authentisierungsmitteln, die dem Vertrauensniveau "gematik-ehealth-loa-substantial" genügen, erfolgen.

Aktuell ist das in der Spezifikation nicht explizit gefordert. Allerdings ist vorgesehen, die Anforderung im kommenden Release zu präzisieren. Das bedeutet, das im Rahmen der Aufklärung die Freigabe durch den Nutzer (z.B. durch Eingabe System-PIN) erfolgen muss, bevor dieser biometrische Authentisierungsmittel nutzen kann.

Es empfiehlt sich, diesen Aspekt schon rechtzeitig zu berücksichtigen.

Die SessionID repräsentiert eine "Subject-Session" zwischen dem IDP_Sek und dem vom IDP_Sek bereitgestellten Authenticator. Das ephemerale Schlüsselpaar auf der Seite des Authenticator hat gemäß A_24768-01 eine maximale Gültigkeit von 3 Minuten. Der public key (PuB) des Schlüsselpaares wird mit der Signatur der SessionID an den IDP übertragen und für den Gültigkeitszeitraum gespeichert. Der Authenticator verwaltet das Schlüsselpaar und sorgt dafür, stets gültige Schlüssel zu verwenden und bei Bedarf (vor Ablauf des Gültigkeitszeitraums) neue zu generieren. Auf Seiten des IDP ist der zur SessionID gehörige public key (PuB) für den Gültigkeitszeitraum zu speichern bis er mit einem neuen (vom Authenticator generierten) PuB überschrieben oder nach Ablauf der Gültigkeit gelöscht wird. Ein Wechsel des Schlüsselpaares führt dazu, dass der Authenticator den neuen PuB im nächsten Aufruf dem IDP bekannt machen muss - dies kann auch im Schritt 6-2 erfolgen.
Die vom IDP generierte SessionID hat ebenfalls eine Gültigkeitsdauer (gemäß A_23212-02 von maximal 1 Stunde), nach deren Ablauf keine Nutzerauthentisierung mit SSO mehr möglich ist und demnach eine aktive Nutzerauthentisierung durchlaufen werden muss.

A_23212 und A_24768-01 widersprechen sich nach unserem Verständnis nicht.

Kapitel 7.4.3 SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP ist Teil des Anhangs und dient der Orientierung für mögliche Implementierungen. Die Schlüsselrotation ist hier nicht abgebildet.

Die Annahme ist richtig, dass die Information zur Authentisierungsmethode im claim amr=urn:telematik:auth:guest:eGK im PAR gesetzt wird. Tabelle 27 enthält alle notwendigen claims des PAR. Weitere claims sind gemäß des Standards aber möglich.

Der Pushed Authorization Request könnte beispielhaft so aussehen:

POST <idp par endpoint>

HTTP/1.1 Host: <iss-idp>

Content-Type: application/x-www-form-urlencoded response_type=code
&state=af0ifjsldkj
&client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2F<as-redirect_uri>%2Fcb &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge_method=S256
&scope=openid+urn%3Atelematik%3Aversicherter &claims%3D%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22essential%22%3Atrue,%22values%22%3A%5B%22urn%3Atelematik%3Aauth%3Aguest%3AeGK%22%5D%7D%7D%7D

Die beschriebene technische Lösung war Konsens zwischen dem BSI und der gematik im Kontext ePA für alle.  In späteren Konsultationen mit dem BSI konnte klargestellt werden, dass das Schutzziels „Abwehr von Replay-Attacken“ durch die Umsetzung anderer Lösungsoption möglich ist. Wir werden auf Basis der Abstimmungen mit dem BSI im Folgerelease die Anforderung so formulieren, dass das Schutzziel - „Abwehr von Replay-Attacken“ - erreicht werden muss. Die technische Umsetzung der aktuellen Formulierung kann als Beispiel in einem Hinweistext dargestellt werden. Die Einhaltung der Anforderung ist durch einen Gutachter zu bestätigen.

Bislang ist die Formulierung der Anforderungen hinsichtlich des claim acr_values im PAR unscharf. Die Rückfrage aus der Kommentierung (GKV_SV_12) wurde bewusst so entschieden, dass ein TI-Fachdienst auch bei acr mit „gematik-ehealth-loa-high“ essential=“true“ ein acr=gematik- ehealth-loa-substantial mit  amr= urn:telematik:auth:mEW im ID-Token akzeptieren muss. Damit wird stringent das Ziel der Akzeptanzfeatures verfolgt, nämlich die selbst bestimmte Entscheidung des Nutzers für den Zugriff auf seine Daten.

Der Bedarf, dass weitere nicht von der gematik normativ geregelte Fachdienste eine Authentisierung des Nutzers mit seiner GesundheitsID nutzen wollen, trat zu diesem Zeitpunkt vorerst in den Hintergrund.

Bei der Implementierung der Akzeptanzfeature sind nun Fragestellungen aufgetreten, die im Rahmen eines Korrekturrelease präzisiert oder angepasst werden müssen.

Vorbehaltlich einer Klärung mit Entscheidungsträgern innerhalb und außerhalb der gematik sollen folgende Änderungen durchgeführt werden:

• Regulatorisch festlegen, dass die TI-Fachdienste, die acr_values=„gematik-ehealth-loa-high“ anfragen, arc=gematik-ehealth-loa-substantial akzeptieren müssen, wenn amr=mEW (ist bereits erfolgt)
• Regulatorisch festlegen, dass die TI-Fachdienste eine geringeres loa nicht akzeptieren müssen (Entscheidung des Fachdienst, was bei einer schwächeren Authentisierung erfolgt)
• Regulatorisch festlegen, dass (nicht von der gematik normativ geregelte) Fachdienste, wenn sie den claims-Request-Parameter acr mit values = „gematik-ehealth-loa-high“ und „essential“=true anfragen, arc=gematik-ehealth-loa-substantial mit amr=mEW im ID-Token akzeptieren können (also kein muss).
• bitte auch FAQ 49 beachten

Damit wird dem Standard entsprochen. Die Implementierung der Standardprodukte muss  nicht TI spezifisch angepasst werden. RPs, die nicht der Reglungshoheit unterliegen können sich auf das standardkonforme Verhalten verlassen.

"A_24547* - Anfrage spezifischer Authentisierungsmittel (amr) durch Relying Parties" regelt den Umgang mit als "essentil=true" durch einen Fachdienst angeforderten amr und deren Zusammenhang mit dem angeforderten acr .

Mit dem Ziel, OIDC Standard Konformität zu erreichen, soll die Verwendung des Claims "acr" mit dem Attribut "essential=true" Standard-konform nur in den Fällen erfolgen, wo eine Unterstützung der Akzeptanzfeatures (Absenkung des Authentisierungsniveaus auf Wunsch des Nutzers) aus regulatorischen Gründen nicht zulässig ist. Derzeit trifft dies für das Organspende-Register und das Vertreterszenario bei ePA3.0 (Oma-Enkel-Szenario) zu.

Im ID-Token signalisiert der sekt. IDP jetzt

• im claim acr des ID-Token die Information über das Vertrauensniveau bekommt, auf dem sich der Nutzer authentisiert hat
• im claim amr des ID-Token die Information über die Authentisierungsmethode bekommt, mit der sich der Nutzer authentisiert hat
• im custom-claim urn:telematik:auth:consent des ID-Token die Information bekommt, ob der Nutzer der Absenkung des Vertrauensniveau zugestimmt hat
• im custom-claim urn:telematik:auth:interactive des ID-Token die Information bekommt, ob der Nutzer sich aktiv authentisiert oder ob eine passive Nutzerauthentifizierung (sso) stattgefunden hat.

Für eine Übergangszeit unterstützen die sektoralen IDP noch den Fall, dass die Information zur Absenkung des Vertrauensniveau durch ein amr=urn:telematik:auth:mEW oder/und amr=urn:telematik:auth:sso im ID-Token signalisiert wird.

Ein Nutzer muss sich mit einem Authentifizierungverfahren "gematik-ehealth-loa-high" authentisieren, um auf Daten mit hohem Schutzbedarf zugreifen zu können.
Alternativ kann sich der Nutzer mit einem Authentifizierungverfahren "gematik-ehealth-loa-substantial" authentisieren, um auf Daten mit hohem Schutzbedarf zugreifen zu können, wenn er nach Aufklärung zugestimmt hat.
Der IDP beglaubigt im ID-Token im claim acr jedoch immer, mit welcher Authentifizierungsstärke die Authentifizierung wirklich durchgeführt wurde.
Hat also ein Nutzer zugestimmt niederschwellige Verfahren zu nutzen und authentisiert sich mit Apple-FaceID, so kann er damit auf Daten mit hohem Schutzbedarf zugreifen. Trotzdem hat er sich nur mit einer Authentifizierungsstärke "gematik-ehealth-loa-substantial" authentisiert. Dem Fachdienst (der ja "gematik-ehealth-loa-high" im Request angefordert hat) wird diese Konstellation signalisiert, indem im ID-Token jetzt gesetzt wird:
amr= urn:telematik:auth:mEW (Nutzer hat in niederschwellige Verfahren für Datenzugriff mit hohem Schutzbedarf eingewilligt)
acr=gematik-ehealth-loa-substantial (Es wurde ein Auth-Verfahren mit der Stärke gematik-loa-substantial durchgeführt)

Für SSO bedeutet das:
Authentisiert sich ein Nutzer bei Fachdienst A mit einem Verfahren gematik-loa-high (z.B. eGK+PIN), so bekommt der Fachdienst im ID-Token
amr=urn:telematik:auth:eGK
acr=gematik-ehealth-loa-high
Für einen weiteren Fachdienst B, der dann SSO nutzen möchte hat das zur Folge, dass der IDP dem Fachdienst B auch das Vertrauensniveau gematik-ehealth-loa-high beglaubigt. Im  ID-Token für Fachdienst B steht:
amr=urn:telematik:auth:sso
acr=gematik-ehealth-loa-high

Authentisiert sich ein Nutzer bei Fachdienst A allerdings mit einem Verfahren gematik-loa-substantial (z.B. FaceID), so bekommt der Fachdienst im ID-Token
amr=urn:telematik:auth:mEW
acr=gematik-ehealth-loa-substantial
Für einen weiteren Fachdienst B, der dann SSO nutzen möchte und keine neue Authentifizierung erzwingt  (A_23030)
hat das zur Folge, dass der IDP dem Fachdienst B auch nur das Vertrauensniveau gematik-ehealth-loa-substantial beglaubigt. Im  ID-Token für Fachdienst B steht:
amr=urn:telematik:auth:sso
acr=gematik-ehealth-loa-substantial

Der empfangende Fachdienst weiß also immer, mit welcher Methode und mit welcher Authentifizierungsstärke sich der Nutzer authentisiert hat und kann auf Basis dieser Information entscheiden, welche Zugriffe auf den Resource-Server er autorisiert.

Die Tabelle in A_23129-03 berücksichtigt die Möglichkeit amr=urn:telematik:auth:sso + acr=gematik-ehealth-loa-substantial noch nicht und muss dahin gehend erweitert werden. Die Anpassung erfolgt mit dem nächsten Release.

• im claim acr des ID-Token die Information über das Vertrauensniveau bekommt, auf dem sich der Nutzer authentisiert hat
• im claim amr des ID-Token die Information über die Authentisierungsmethode bekommt, mit der sich der Nutzer authentisiert hat
• im custom-claim urn:telematik:auth:consent des ID-Token die Information bekommt, ob der Nutzer der Absenkung des Vertrauensniveau zugestimmt hat
• im custom-claim urn:telematik:auth:interactive des ID-Token die Information bekommt, ob der Nutzer sich aktiv authentisiert oder ob eine passive Nutzerauthentifizierung (sso) stattgefunden hat.

Für eine Übergangszeit unterstützen die sektoralen IDP noch den Fall, dass die Information zur Absenkung des Vertrauensniveau durch ein amr=urn:telematik:auth:mEW oder/und amr=urn:telematik:auth:sso im ID-Token signalisiert wird.

Fachdienste, die schützenwerte Daten mit Sicherheitsniveau high haben, müssen auch immer beim IDP (acr_values im Pushed Authorization request) "hoch" anfordern. Es geht ja um den Schutz der Daten. Der Nutzer hat nun aber das Recht selbst zu entscheiden, das er sich lieber komfortabel authentisiert (anmeldet) im vollen Bewusst sein, dass er damit ein gewisses Risiko des Missbrauchs durch Fremde eingeht. Der Fachdienst, der ja eigentlich eine Authentisierung "hoch" anfordert um die daten des Nutzers "hoch" zu schützen muss nun aber nach neuer Afo die Nutzerentscheidung respektieren. Die Nutzerentscheidung wird im ID-Token als amr=urn:telematik:auth:mEW mitgegeben.

Konkret ist das der Fall, wenn ein Fachdienstes fragt mit „gematik-ehealth-loa-high“ an und der Nutzer authentifiziert sich „gematik-ehealth-loa-substantial“ (amr=urn:telematik:auth:mEW). Der Fachdienst muss dann diese Nutzerentscheidung akzeptieren.

Für den Fall SSO bedeutet das in Konsequenz

1. Die Frontends alle für SSO in Frage kommenden (TI)-Dienste sind in das ePA-FdV eingebettet
2. Das Authenticator-Modul des sekt. IDP ist ebenfalls Teil des ePA-FdV oder eine separate APP
3. Der Nutzer hat im ePA-FdV explizit seine Zustimmung zur Nutzung SSO für jeden relevanten Dienst abgegeben
4. Der Nutzer hat (beim ersten Zugriff auf einen Fachdienst oder bereits vorher) seine Zustimmung gegeben, Authentisierungsmittel (auch bei Fachdiensten, die „gematik-ehealth-loa-high) zu nutzen, welche nur die Voraussetzungen für „gematik-ehealth-loa-substantial“ erfüllen

Nach Anforderungslage darf der sekt. IDP nur ein Token ausstellen, wenn:

1. Der Nutzer sich auf „gematik-ehealth-loa-high“ oder auf „gematik-ehealth-loa-substantial“ (amr=urn:telematik:auth:mEW) authentifiziert hat
2. In beiden Fällen kann auch SSO genutzt werden, die Signalisierung für ein durchgeführtes SSO erfolgt durch amr=urn:telematik:auth:sso im ID-Token. Der claim acr im ID-Token hingegen signalisiert das Niveau, auf dem authentifiziert wurde, also „gematik-ehealth-loa-high“ oder „gematik-ehealth-loa-substantial“

Es ist richtig, dass nicht explizit gefordert wird, dass ein Fachdienst „gematik-ehealth-loa-substantial“ (amr=urn:telematik:auth:sso) akzeptieren muss, allerdings schließt nach unserer Meinung und Interpretation der Spezifikation (amr=urn:telematik:auth:sso) derzeit ein (amr=urn:telematik:auth:mEW) mit ein. Biometrie und SSO wäre also im Kontext ePA-FdV möglich.

A_23202-01 wird entsprechend erweitert und mit dem nächsten Release korrigiert.

Im ID-Token signalisiert der sekt. IDP jetzt

• im claim acr des ID-Token die Information über das Vertrauensniveau bekommt, auf dem sich der Nutzer authentisiert hat
• im claim amr des ID-Token die Information über die Authentisierungsmethode bekommt, mit der sich der Nutzer authentisiert hat
• im custom-claim urn:telematik:auth:consent des ID-Token die Information bekommt, ob der Nutzer der Absenkung des Vertrauensniveau zugestimmt hat
• im custom-claim urn:telematik:auth:interactive des ID-Token die Information bekommt, ob der Nutzer sich aktiv authentisiert oder ob eine passive Nutzerauthentifizierung (sso) stattgefunden hat.

Für eine Übergangszeit unterstützen die sektoralen IDP noch den Fall, dass die Information zur Absenkung des Vertrauensniveau durch ein amr=urn:telematik:auth:mEW oder/und amr=urn:telematik:auth:sso im ID-Token signalisiert wird.

Entsprechend der Anforderung A_22706-01 - "ID-Token" des sektoralen IDP wird vom sektoralen IDP ein ID-Token gemäß OIDC Standard OpenID Connect Core 1.0 (section-2) erstellt. Der claim amr wird, wenn vorhanden, als JSON-Array im ID-Token geliefert.

Die Anforderung A_23202-01 formuliert lediglich, dass ein Fachdienst, wenn amr= urn:telematik:auth:mEW  bzw. amr=urn:telematik:auth:sso enthält, das Vertrauensniveau acr=gematik-ehealth-loa-substantial akzeptieren muss.

Der sektorale IDP kann den anfragenden Fachdienst weitere Werte im amr-array liefern.

Hat sich ein Nutzer beispielsweise nach Einwilligung zur Absenkung des Vertrauensniveaus und nach Einwilligung zur Nutzung biometrischer Authentifizierungsverfahren mit Face-ID oder Fingerprint authentifiziert, so kann das ID-Token diese Information zusätzlich im amr angeben ( urn:telematik:auth:other). Die claims im ID-Token wären dann für dieses Beispiel so belegt:

acr = gematik-ehealth-loa-substantial
amr = [ urn:telematik:auth:mEW, urn:telematik:auth:other ]

Im ID-Token signalisiert der sekt. IDP jetzt

• im claim acr des ID-Token die Information über das Vertrauensniveau bekommt, auf dem sich der Nutzer authentisiert hat
• im claim amr des ID-Token die Information über die Authentisierungsmethode bekommt, mit der sich der Nutzer authentisiert hat
• im custom-claim urn:telematik:auth:consent des ID-Token die Information bekommt, ob der Nutzer der Absenkung des Vertrauensniveau zugestimmt hat
• im custom-claim urn:telematik:auth:interactive des ID-Token die Information bekommt, ob der Nutzer sich aktiv authentisiert oder ob eine passive Nutzerauthentifizierung (sso) stattgefunden hat.

Für eine Übergangszeit unterstützen die sektoralen IDP noch den Fall, dass die Information zur Absenkung des Vertrauensniveau durch ein amr=urn:telematik:auth:mEW oder/und amr=urn:telematik:auth:sso im ID-Token signalisiert wird.

Die Länge des String für organization_name ist auf 128 Zeichen begrenzt. Als RegEx-Patern ist zu verwenden:

^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{1,128}$ 

Die Spezifikation wir im folgenden Release dahin gehend präzisiert.

Die Nutzerpräferenz, welche im FdV gebundenen Dienste mit SSO nutzbar sein sollen, ist nur lokal im FdV gespeichert. Auf Seiten des IDP-Sek ist die generelle Einwilligung in die Nutzung von SSO und die Einwilligung zur Nutzung substantieller Authentisierungsverfahren persistiert. Liegt eine generelle SSO-Einwilligung (nach erfolgter Aufklärung des Nutzers) IDP-seitig vor, wird mit folgendem Ablauf zur Nutzung verfahren:

1. Die Relying Party stellt einen PAR an den sektoralen IDP
2. Die Antwort des IDP-Sek mit der Request-URI wird im FdV-Client empfangen 
3. Auf Basis der vorliegenden Nutzerpräferenzen wird die Request-URI um einen Query-Parameter sso_instance_id ergänzt für den Fall, dass zum angefragten Dienst (e-Rezept, ePA, OGR, etc.) eine positive SSO-Präferenz vom Nutzer eingestellt wurde.
4. Die sso_instance_id enthält ein UUID Type  4 oder Type 5 (String der Länge 36: 32 hexadecimal characters and 4 hyphens) und wird ausschließlich dann mit gesendet, wenn eine positive Nutzerpräferenz zum Zeitpunkt der Request-Weiterleitung vorlag. Sollte der übertragene Wert der sso_instance_id nicht dem Format UUID4/UUID5 entsprechen, darf der Authenticator die Anfrage des FdV mit einer Fehlermeldung error=invalid_request abbrechen
5. Der Authenticator wertet den Parameter aus und verwendet eine bestehende Subject-Session zur Authentisierung, ohne dass der Nutzer mit dem Authenticator interagiert. Wenn keine Subject-Session besteht, kann der Authenticator dem SSO-Wunsch nicht nachkommen und MUSS eine interaktive Nutzerauthentisierung aussteuern.

Abweichend zum Ablauf, beschrieben in gemSpec_IDP_Sek 2.5.0 Kapitel "7.5 Unterstützung Single-Sign-On auf Anwendungsebene" kann für die erste Stufe der Einführung ePA 3.0

• die Einwilligung des Nutzer für ein SSO je Fachmodul wird im ePA-FdV erhoben und dort gespeichert.
• auf die Übermittlung von authorization_details im PAR vom Authorization Server an den sektoralen IDP verzichtet werden, da die Einwilligung beim Authorization Request an den jeweiligen Authorization Server nicht als authorization_details übermittelt wird.
• die notwendige Informationen "appInstanceID" durch das ePA-FdV dem Authenticator Modul bekannt gemacht werden.

Diese Implementierungsoption ist nach Absprache mit den beteiligten Herstellern eine Übergangslösung. Eine zukunftssichere Standard-konforme Lösung wird erarbeitet, spezifiziert und in einem späteren Release umgesetzt. 

Folgende Übersicht stellt die Nutzungsmöglichkeiten eines sektoralen IDP im Kontext bestimmter Anwendungsfälle dar. Anhand von Beispielen wird gezeigt, wie ein Pushed Authorization Request (PAR) im jeweiligen Szenario aussehen soll.

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter
 &claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue,%22values%22%3A%5B%22gematik-ehealth-loa-high%22%5D%7D%7D%7D

{
    "id_token": {
        "acr": {
            "essential": true,
            "values": [
                "gematik-ehealth-loa-high"
            ]
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg==" ]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:eGK"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter

{
    "id_token": {
        "acr": {
            "essential": false,
            "values": [
                "gematik-ehealth-loa-high"
            ]
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg==" ]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:eID"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg==" ]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-substantial",
  "amr": [
    "urn:telematik:auth:mEW"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="

]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-substantial",
  "amr": [
    "urn:telematik:auth:sso"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter

{
    "id_token": {
        "acr": {
            "essential": false,
            "values": [
                "gematik-ehealth-loa-high"
            ]
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:eGK"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:eID"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter

{
    "id_token": {
        "acr": {
            "values": [
                "gematik-ehealth-loa-high"
            ],
            "essential": false
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:eGK"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter

{
    "id_token": {
        "acr": {
            "values": [
                "gematik-ehealth-loa-high"
            ],
            "essential": false
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-substantial",
  "amr": [
    "urn:telematik:auth:mEW"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234
 &state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-mvd94bdd5i1d0x7FTD_sFNRK4cxx-vDIbpfL2u9W
 &code_challenge_method=S256
 &response_type=code
 &nonce=274312:dj83hs9s
 &scope=openid%20urn%3Atelematik%3Adisplay_name%20urn%3Atelematik%3Aversicherter
 &claims=%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22values%22%3A%5B%22urn%3Atelematik%3Aauth%3Aguest%3AeGK%22%5D,%22essential%22%3Atrue%7D%7D%7D

{
    "id_token": {
        "amr": {
            "values": [
                "urn:telematik:auth:guest:eGK"
            ],
            "essential": true
        }
    }
}

{
  "typ": "JWT",
  "kid": "000200014507016890001",
  "alg": "ES256",
  "x5c": [
    "MIIDGDCCAr+gAwIBAgIEZGK9STAKBggqhkjO...G9uxw7Yg=="]
}.
{
  "iat": 1732185594,
  "exp": 1732185894,
  "iss": "https://your-idp.de",
  "sub": "qRM1MTUoEjzrQRjFyXlAkWZULkPFfhHeGvq4TdhPeR8=",
  "aud": "https://your-relying-party.de",
  "nonce": "2bdbc819-74fb-465b-b7f4-05feb1362f3f",
  "acr": "gematik-ehealth-loa-high",
  "amr": [
    "urn:telematik:auth:guest:eGK"
  ],
  "urn:telematik:claims:profession": "1.2.276.0.76.4.49",
  "urn:telematik:claims:id": "L436976238",
  "urn:telematik:claims:organization": "450701689",
  "urn:telematik:claims:display_name": "Erika Sophie Mustermann"
}.
{signature}

Der doppelte Dialog zu SSO ist nicht erforderlich. Bei einer Änderung der Anforderungen müssen alle derzeit aufgeführten Bedingungen übernommen werden. Der Nutzer muss über die Risiken für SSO ausreichend aufgeklärt werden, er muss der Verwendung für jeden Fachdienst aktiv zustimmen, er muss konfigurieren können für welche Fachdienste er seine Zustimmung zu SSO erteilt hat, in der Default-Einstellung ist kein SSO konfiguriert usw.. Die Anforderungen sollten dabei atomar sein und jeweils nur eine prüfbare Anforderung enthalten.

Das BSI sieht keinen Widerspruch zur Afo A_23208-01, wenn sichergestellt ist, dass die Möglichkeit die Dienste einzeln, z.B. über mehrere Checkboxen, zu konfigurieren („Dienste einzeln auswählen“), direkt erreichbar ist. Zusätzlich muss für den Nutzer transparent sein, welche Dienste er für SSO aktiviert. Die Umsetzung einer Lösung, bei welchem im initialen Dialog zu SSO alle Dienste mit einer einzigen Checkbox aktiviert werden können, ist möglich.

Die Anforderungen für die Produktzulassung eines sektoralen Identity Provider sind im aktuellen Produkttypsteckbrief unter dem Kapitel 3 „Normative Festlegungen“ zu finden. Hier sind alle normativen Festlegungen, die für die Herstellung und den Betrieb des Produktes notwendig sind, aufgelistet.

Im Falle des Sektoralen Identity Provider zählen hierzu:

1. Funktionale Eignung
   1. Produkttest/Produktübergreifender Test
   2. Herstellererklärung funktionale Eignung
2. Sicherheitstechnische Eignung
   1. Herstellererklärung sicherheitstechnische Eignung
   2. Sicherheitsgutachten
   3. Produktgutachten

Darüber hinaus beachten Sie bitte die zugehörige Verfahrensbeschreibung im Fachportal https://fachportal.gematik.de/schnelleinstieg/downloadcenter/zulassungs-bestaetigungsantraege-verfahrensbeschreibungen.

Für sektorale IDP gilt:

"Öffentliche/r Schlüssel für JWT"

Das Entity Statement eines sektoralen IDP muss als signiertes JWT abrufbar sein (siehe A_22643 - Entity Statement des sektoralen IDP).
Zur Prüfung der Signatur des JWT ist ein öffentlicher Schlüssel notwendig.
Dieser öffentliche Schlüssel, mit dem die Signatur geprüft werden kann, ist der "Öffentliche/r Schlüssel für JWT", welcher bei der Registrierung des sektoralen IDP anzugeben ist.

"Öffentliche/r Schlüssel für TLS" 

Die HTTP(S)-Verbindungen zwischen Fachdiensten und sektoralen IDPs müssen als mTLS-Verbindungen realisiert werden (siehe A_22864 - Umsetzung von Operationen in einer Vertrauenswürdigen Ausführungsumgebung (VAU)).

Diese öffentlichen Schlüssel für die Transportverschlüsselung ist der "Öffentliche/r Schlüssel für TLS", welcher bei der Registrierung des sektoralen IDP anzugeben ist.

Allgemein gilt für die Schlüsselerzeugung die Anforderung:

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  

Die Prüftiefe des HSM MUSS dabei den in [A_22829] angegebenen Standards entsprechen.<=

Für Fachdienste gilt:

Für die Registrierung von Fachdiensten gilt:

A_23045 - Registrierung des Fachdienstes
Anbieter von Fachdiensten MÜSSEN bei der Registrierung ihrer Authorization-Server am Federation Master die von ihnen erwarteten Attribute in scopes (siehe Abschnitt ML-128467) beschreiben und dem Federation Master zur Verfügung stellen. Die Registrierung MUSS ebenso die absolute URI des Fachdienstes im Internet umfassen (seine Client-ID) sowie dessen Signaturschlüssel für das Entity_Statement.

Um den Vertrauensraum sicherzustellen, müssen Änderungen dieser Schlüssel auch nach der Registrierung im produktiven Betrieb immer über den organisatorischen Prozess dem Federation Master übermittelt werden.

In folgenden Folien finden sich Informationen zum DiGA-Integrator (Stand 16.01.2025):

Aus Sicht der gematik ist das zulässig sofern für alle Mandanten gesichert ist dass deren sektoraler IDP den zugrunde liegenden Spezifikationen genügen.

Jede Kasse wird als eigener IDP mit eigenen Endpunkten und Entity Statements geführt. Ein Betreiber kann dahinter aber denselben Dienst stehen haben und die Kassen als Mandanten pflegen. Auf einem physischen Multi-Tenant Sek-IDP mit einer Anbieter- und Produktzulassung der gematik für das System, den Betrieb und die bewerteten Identifizierungs- und Authentifikations-Mechanismen können beliebig viele logische Sek-IDP-Instanzen aufgebaut werden. Die kommerzielle Abbildung, wem gehört die physische Instanz und mögliche Modelle für eine Rücklizensierung / Weiterveräußerung des Sek-IDP-Ansatzes, sind von der Abbildung des Sek-IDP für die gematik nicht relevant. Die gematik wendet sich immer an den Inhaber der Produkt - / Anbieterzulassung des (physischen) Sek-IDP und bespricht mit diesem alle Fragen rund um die logischen Instanzen der Krankenkassen auf dieser physischen Instanz.

Es besteht eine Informationsverpflichtung über Mandanten des Anbieters sektoraler IDP. Die gematik wird über die aktuellen Mandanten des jeweiligen Anbieters informiert.

Wenn der sektorale IDP eines weiteren Mandanten über bereits zugelassene Prozessabläufe und Funktionalitäten (die z. B. bereits für bestehende Mandanten genutzt werden) abgebildet werden kann (z. B. gleiche Art der Anbindung an Kassensysteme, gleicher Prozess zur Zuweisung von Schlüsselmaterial, gleiche oder eine Unterauswahl von Authentisierungsmethoden), dann benötigt der Anbieter keine neue Produkt- oder Anbieterzulassung, um den neuen Mandanten auf dem System abzubilden. Delta-Gutachten und eine Delta-Zulassung werden nur im Falle einer Erweiterung des Funktionsumfangs, Veränderungen an den Schnittstellen zu den Systemen der Mandanten, Veränderungen an den Sicherheitsvoraussetzungen und insbesondere bei zusätzlichen Authentisierungsverfahren erforderlich. Veränderungen im Bereich der Darstellung der Funktionen für den Endnutzer (UI, CI, CD) sind irrelevant, solange sie nicht Vorgaben unterlaufen.

Sollte ein logischer Mandant (KK) nur eine Auswahl aus dem Set der in der Anbieter – und Produktzulassung freigegebenen Ident- / Authent-Verfahren und genehmigten Prozesse benutzen, so ist kein erneutes Sicherheitsgutachten bzw. eine erneute Zulassung oder Delta-Zulassung bei der gematik erforderlich.

Sollte ein logischer Mandant (KK) im Vergleich zum Set der in der Anbieter – und Produktzulassung freigegebenen Ident- / Authent-Verfahren und genehmigten Prozesse weitere oder andere Ident- / Authent-Verfahren und / oder Prozesse benutzen, so ist in dem Fall ein erneutes (Delta-) Anbieter- und Produkt-Sicherheitsgutachten bzw. eine Delta-Zulassung bei der gematik erforderlich.

Die Aufnahme eines neuen Mandanten erfolgt mittels Anzeige / Registrierung des neuen logischen Tenant gemäß Anforderungen gematik-Sek-IDP-Spezifikation (mit zugehörigen Prozessen, Zuweisung Kennung und Schlüsselmaterial durch die gematik).

Die logischen Mandanten können alle Ressourcen des physischen Systems (Storage, Server, HSMs) in einem shared Modus nutzen. Eine Abbildung pro Nutzer n=1  ist irrelevant. Es erfolgt immer die Zuordnung auf der Ebene der logischen Mandanten (Krankenkassen) als Summe der Nutzer pro Krankenkasse. Dabei müssen die Mandanten auf allen Ebenen logisch bzw. über Mechanismen der Software getrennt werden, so dass alle Prozesse eines Mandanten (z. B. Registrierung und De-Registrierung des Mandanten, Konfiguration des mandantenspezifischen Kontextes, DNS-Einträge) ohne Einfluss auf andere Mandanten ablaufen bzw. durchgeführt werden können. Konkret bedeutet dies, dass je Mandant dedizierte Enklaven gestartet, dediziertes Schlüsselmaterial - in unabhängig vollziehbaren Zeremonien - registriert und dedizierte Storage-Bereiche genutzt werden müssen. An den IDP eines Mandanten gerichtete Requests werden durch das System an eine dem Mandanten zugeordnete Enklave geroutet, die sich mittels des nur ihr zugänglichen Schlüsselmaterials als Service mit der dem Mandanten zugeordneten Identität ausweist. Die Requests bzw. Sessions verschiedener Nutzer werden innerhalb der Enklave des IDP-Mandanten z. B. auf Thread-Ebene isoliert. Die Bewertung der sicherheitstechnischen Qualität dieser nutzerbezogenen Trennung im Verarbeitungskontext ist Gegenstand des Produktgutachtens.

Zur Überprüfung der Erreichbarkeit des sektoralen IDP werden durch die gematik regelmäßig invalide Requests an diese Schnittstellen gemäß Entity Statement (siehe Tabelle: "Body Entity Statement des sektoralen IDP") gestellt:

• pushed_authorization_request_endpoint
• token_endpoint 

Als Ergebnis der Request wird ein Fehlercode gemäß [OpenID Connect Federation 1.0#rfc.section.7.5] erwartet. Testidentitäten müssen demnach in der produktiven Umgebung nicht bereitgestellt werden.

Es gibt darüber hinaus keine Anforderungen an Validierungsidentitäten. Selbstverständlich können sektorale IDP Validierungsidentitäten implementieren, wenn sie diese zur Sicherstellung ihrer Funktionalität benötigen. Normative Vorgaben für Validierungsidentitäten gibt es jedoch nicht.

Anbietern steht es frei sich, falls benötigt, Validierungsaktenkonten für eigene Zwecke anzulegen welche idealerweise den Einigungen zur ePA dahingehend folgen,  dass nur Versichertennummern aus dem von der gematik  freigegebenen Nummernkreis [gem. gemSpec_PK_eGK] verwendet werden. Entsprechend Card-G2-A_3820 MUSS die Versichertennummer X0000nnnnP, mit nnnn aus der Menge {0001 .. 5000} und P = Prüfziffer entsprechen.

Die Mechanismen der Föderation decken kassenübergreifende Anwendungsfälle ab. 

Für Anwendungen, die nicht übergreifend durch mehrere IDPs unterstützt werden sollen, ist es ausreichend diese direkt bei den jeweiligen IDPs zu registrieren. Die Föderation bietet hier keinen Mehrwert da beide Kommunikationspartner sich ohnehin kennen und vertrauen.  (Siehe den letzten Absatz Kapitel 2.1 in gemSpec_IDP_Sek). Direkte 1:1 Beziehungen wie etwa auch zum Signaturdienst im Kontext der ePA werden nicht über die Föderation behandelt, sondern über eine direkte Anbindung an den sektoralen IDP der jeweiligen Kasse. Der IDP muss diese lediglich entsprechend A_23021 differenzieren.

Im von Ihnen skizzierten Anwendungsfall ist der Anwendung (App) die Kasse bzw. der zugehörige IDP des Nutzers nicht bekannt. Für diesen Fall ist beschrieben, was Federation Master und Fachdienst bereitstellen müssen, um dem Nutzer eine Auswahl zu ermöglichen. Der Nutzer muss dann eine Auswahl treffen, damit der Authentifizierungsablauf überhaupt starten kann. 

Wenn der Fachdienst (bzw. die App) die Zugehörigkeit des Nutzers zu einer Krankenkasse oder -versicherung und damit zu einem konkreten IDP kennt (z.B. weil in einer vorherigen Nutzung bereits eine Zuordnung stattgefunden hat), dann ist die Auswahl durch den Nutzer nicht notwendig.

Der Anwendungsfall AF_10100 muss also nur ausgeführt werden, wenn der Fachdienst die Zuordnung des Anwenders zu seinem IDP nicht kennt.

Dazu Zeile „Ablauf“ in der Tabelle zum AF_10100:

• Im Ablauf der Nutzung eines Fachdienstes (siehe Abbildung  - Aktivitätsdiagramm  "Auswahl sektoraler Identity Provider") findet eine Verzweigung zum Federation Master in dem Fall statt, wenn der Fachdienst die Zuordnung des Anwenders zu seinem IDP nicht kennt.

Die Anforderung A_21332  ist nicht neu im Kontext der sektoralen IDP, sondern besteht im Kontext E-Rezept schon seit Anfang 2021 mit den beiden zugeordneten Prüfverfahren.

Seitens Hersteller kann alles getestet werden. Der Gutachter kann prüfen, ob Ciphersuiten unterstützt werden, die nicht unter Punkt (1) der Anforderung und nicht in TR-02102-2, Abschnitt 3.3.1 Tabelle 1 aufgeführt sind.

Die Vorgaben zum Notfallmanagement in C5 decken generell dieselben Bereiche wie der BSI-Standard 100-4 ab.

Entsprechend der Kreuzreferenztabelle des BSI zur Bewertung des C5 ist dessen Umsetzung mindestens Gleichwertig und damit akzeptabel.

Die Einschränkung: „die diese Anwendung nutzen.“ bezieht sich auf die Einordnung zum Nutzerkreis.
Das heißt, beim „Anbieter sektoraler IDP KTR“ sind die Nutzer die Versicherten.
Versicherte = Gesamtnutzerzahl = 72,3 Mio gesetzlich Vers. + 8,8 Mio privat Vers. = 81,1 Mio

Die konkret für die Anteilsbetrachtung relevanten Nutzer sind die bei allen Mandanten (=Kassen) des Anbieters in Summe vorhandenen Versicherten.

Das ist unabhängig davon, ob diese Versicherten den IDP „aktiv nutzen“, sondern dass sie den IDP potentiell nutzen könnten.

Der Sinn der anteiligen Performancevorgabe ist, dass alle Anbieter zusammen die geforderte Last (hier 450 Requests pro Sekunde) bereitstellen - aufgeteilt jeweils zur Anzahl der bei ihren Mandanten zugehörigen Versicherten. Zusätzlich ist noch ein Sockel (10 Requests pro Sekunde) eingebaut, der für eine Grundlast und für Systemabfragen notwendig ist.

Für die Annahme „Eigene Kunden des Anbieters = derzeit 8 Mio Versicherte Krankenkasse xy“ gilt somit:

Für den Anbieter sektoraler IDP KTR, bei welchem alle Versicherten der Krankenkasse xy Mandant sind, würde das bedeuten:

MA = 8/81,7 = 0,098 ≈ 0,10

Die derzeitig vorgeschriebene Last beträgt hier dann: 10 + 450x0,10 = 55

Hinweis:

Einem Anbieter wird eine Adaptierung im Zuge eines Aufbaus oder Abbaus der Zahlen der Versicherten ihrer Mandanten eigenverantwortlich zugetraut. Anlassbezogen kann bei auftretenden Performance-Problemen, die in den Rohdaten jederzeit nachvollzogen werden können, die Performancevorgeben überprüft werden.

Darüber hinaus möchten die Kassen für ihre eigenen Anwendungen, die nicht in diesen Performance-Vorgaben enthalten sind, dieselbe von ihnen bereitgestellte Infrastruktur nutzen und sind daher intrinsisch motiviert, eine höhere Performance im System vorzusehen. Sollte sich - insbesondere bei einer größer werdenden Anzahl von Anwendungen in der TI - die Performancevorgabe erhöhen, wird das in einem Folgerelease für alle Anbieter bekanntgegeben. Eine solche Skalierung ist grundsätzlich immer zu erwarten.

Es gibt einen Grund, warum der Versicherte seine Registrierung erneuert bzw. eine erneute Registrierung durchführt.

Die Grundannahme ist, dass die alte (bisherige) Registrierung dann hinfällig ist und der IDP aufgrund der neuen Registrierung die Nutzung ermöglicht. Deshalb ist die alte Registrierungsinformation bei einer erfolgreichen neuen Registrierung zu entfernen und nur die letzte in den Bestandsdaten zu reporten. Eine Mehrfachregistrierung mit unterschiedlichen Verfahren gleichzeitig ist weder sinnvoll noch vorgesehen.

Bei der Überprüfung des Kontextes der Anforderung A_22504 haben wir festgestellt, dass diese Anforderung für die aktuelle Produktversion zum sektoralen IDP nicht mehr relevant ist und ignoriert werden kann.

Wir korrigieren die Zuweisung der Anforderung zum sektoralen IDP, so dass sie in der nächsten Veröffentlichung des Produktsteckbriefes nicht mehr enthalten ist.

Unsere Rechtsabteilung teilt die Auffassung, dass der Zugriff auf die ePA gemäß § 336 Abs. 2 SGB V getrennt von der einer elektronischen Identität zu sehen ist und demnach parallel dazu angeboten werden kann. Beide Zugriffsmöglichkeiten basieren auf unterschiedlichen gesetzlichen Grundlagen.

Jedoch gelten damit dann auch die Vorgaben und Freiheiten für die eID nicht auch für diesen Weg, sodass man nach Ablauf der Duldung des BfDI für eine Absenkung des Schutzniveau nur noch über eGK bzw. nPA als zulässige Authentisierungsmittel sprechen würde.

Im Migrationsfall  startet die Gültigkeitsdauer einer existierenden Gerätebindung entsprechend A_22750-01 mit dem Zeitpunkt zu dem die Gerätebindung ursprünglich angelegt wurde. Alternativ muss eine neue Gerätebindung nach der  Migration angelegt werden.

Wenn ein Nutzer mit einem Verfahren identifiziert wurde, das gemäß der veröffentlichten Liste der zulässigen Identifikationsverfahren ("Festlegung der zulässigen Identifikationsverfahren" (https://fachportal.gematik.de/schnelleinstieg/smartcards-und-identitaeten-in-der-ti/identitaeten)  verwendet werden darf, so ist dieser nicht erneut zu identifizieren, bevor er seine Gesundheits-ID nutzen darf.

Die Zustellung der PIN mit PostIdent Zustellung ist valide. Es ist nur kein zulässiges Verfahren um als alleiniges Ident der Gesundheits-ID verwendet zu werden. Demnach können auf dem beschriebenen Weg eGK und PIN ausgeliefert und dann diese Karte als Identmedium für den IDP verwendet werden. Es ist also nicht so, dass die eGK und PIN ebenfalls zwingend in einem Verfahren mit einer Identifizierung gemäß "gematik-ehealth-loa-high" verknüpft werden müssen. Dort gelten die bestehenden Festlegungen und Prozesse.

In der Vorab-Klärung zur Spezifikationserstellung wurde das Anfragen einzelner claims zugunsten der scopes abgelehnt. Daher wurde der Weg über die acr_values und den acr-Rückgabewert gewählt. Der sektorale IDP lehnt den Request eines Fachdienstes nicht zwingend ab, wenn das acr_values nicht in ausreichender Güte erfüllt werden kann, sondern gibt dem Fachdienst im claim acr des ID-Token das Vertrauensniveau des durchgeführten Authentisierungsverfahren zurück (siehe Anforderung A_ 23129).  Welches Authentifizierungsverfahren durchgeführt wurde, wird im claim amr im ID-Token dem Fachdienst zurückgegeben.

Der Fachdienst muss prüfen, ob das im ID-Token im Feld acr gelistete Vertrauensniveau der durchgeführten Authentisierung für den Zugriff auf ihre Fachdaten ausreicht. So wäre es auch möglich, dass der Fachdienst bei einer weniger starken Authentisierung verschiedene Operationen nicht anbietet bzw. bei deren Aufruf eine erneute Authentisierungsanfrage stellt.

Der derzeit aktuelle OpenID Federation 1.0 enthält eine Reihe Anpassungen und Erweiterungen bzgl. des OpenID Connect Federation 1.0 - draft 21, der als Grundlage für die erste Veröffentlichung der Spezifikation zu den sektoralen IDPs gedient hat. Wir planen aus diesem Grund eine Anpassung der aktuellen Spezifikation an den relevanten Punkten. Je nach Abstimmung und Aufwand wäre das Ziel die Aktualisierung noch 2025 zu veröffentlichen.