Fragen & Antworten (FAQ)

Die Spezifikationen zur TI-Föderation werden im Fachportal der gematik veröffentlicht. 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 in 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-02, A_20314-01, A_20699-03, A_20951-01, A_22328, A_22290, A_20465) und in gemSpec_IDP_Frontend (A_20525, A_19908-01, A_20700-07, A_20526-01) 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.

Die Anforderung A_22306 ist nicht korrekt formuliert. Erfüllt werden soll diese Bedingung:

"Der Anbieter des sektoralen Identity Provider MUSS auf dem WebFrontend  für den Auth-Endpunkt  (siehe A_22744) 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)."

Die Formulierung wird mit der nächsten Auslieferung korrigiert.

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".

Die Formulierung der Anforderung A_22301-01 basiert noch auf der Implementierung des Fasttrack. Beim Fasttrack Schritt 2 wurde der Authorization Request vom zentralen IDP-Dienst über das FdV an den sektoralen IDP  gestellt. Dieser Authorization Request enthielt auch den vom zentralen IDP-Dienst ausgestellten state-Parameter. Auf diesen state-Parameter bezieht sich A_22301-01.

Die Abläufe in der Föderation sind an dieser Stelle anders. Das FdV erhält einen vom sektoralen IDP ausgestellten URI entsprechend des RFC9126. Dieser enthält nach Standard nicht den vom zentralen IDP-Dienst ausgestellten state-Parameter. Der state-Parameter wird nur noch vom Authorization Server bei Entgegennahme des Authorization Code geprüft, welche den state-Parameter auch erstellt hat (Schrit 9 im App-App-Flow). Nach Umstellung der Abläufe von Fasttrack auf TI-Föderation ist der state-Parameter am Frontend nicht sinnvoll prüfbar.

Die Anforderung muss diesbezüglich korrigiert werden.

Die Anmerkung ist korrekt.  Die gemSpec_IDP_FD beschreibt den allgemein gültigen Ablauf für Fachdienste der TI-Föderation. Die Kommunikation zwischen den Frontends und dem Authorizationserver bei ePA entspricht nicht dem OAuth2-Standard. Der erste Schritt im Anwendungsfall A_10117 ist bei ePA spezifisch und anders umgesetzt, deshalb hier auch nicht anwendbar.

Wir werden AF_10117 bei der nächsten Veröffentlichung dahingehend allgemeiner beschreiben.

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 folgenden Vorgaben berücksichtigen, die diese im besten Fall später normativ für alle sektoralen IDPs gelten werden:

{
  "authorization_details": [
    {
      "type": "UserPreferenceSSO",
      "sso-preferences": [
        [
          "<iss aus dem Entity Statement des Fachdienstes A>",
          "<client_name aus dem Entity Statement des Fachdienstes A>",
          "false"
        ],
        [
          "<iss aus dem Entity Statement des Fachdienstes B>",
          "<client_name aus dem Entity Statement des Fachdienstes B>",
          "true"
        ]
      ],
      "applicationId": "<UUID APP-Instance>"
    }
  ]
}

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.

Der redaktionelle Fehler "gematik-loa-high" = "gematik-ehealth-loa-high" wird korrigiert.

Die Anforderung  A_25875 wurde noch nicht auf die Erweiterung um die Akzeptanzfeature angepasst. Die vollständige Anforderung muss lauten:

A_25875 - Aktive Nutzerauthentifizierung im Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob der Nutzer sich im laufenden Anwendungskontext bereits aktiv auf dem Vertrauensniveau "gematik-ehealth-loa-high" oder  auf dem Vertrauensniveau "gematik-ehealth-loa-substancial" zu welcher eine Einwilligung des Anwenders zur Nutzung dieses Verfahrens zum Zugriff auf Daten mit hohem Schutzbedarf vorliegt, authentifiziert hat. [<=]

Die Anforderung wird mit dem nächsten Wartungsrelease korrigiert.

Die Anforderungen bzgl. des guest-account müssen präzisiert werden. Abweichend von A_23197 soll beim guest-account ein Zufallswert im claim sub des ID-Token gesetzt werden. Ein Fachdienst ist mit dieser Information in der Lage, Zugangsrechte zur eigentlichen Ressource zu vergeben. Der Zufallswert darf nicht zu einem User gespeichert werden, er muss bei jeder Ausstellung des ID-Token neu berechnet und vergeben werden. 

Die Änderung in der Spezifikation wird mit dem Folgerelease als Korrektur ausgeliefert.

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.

Zur Korrektur des redaktionellen Fehler wurde am 23.07.2024 ein Hotfix (Release IDP_24_8) zur Spezifikation geliefert. Die fehlende Anforderung A_22867 ist dort ergänzt.

Die Beobachtung ist korrekt. Die Tabelle 40  "Header-claims des ID_TOKEN des sektoralen IDP" muss um den fehlenden Parameter epk (ephemeral public key des Senders) ergänzt werden.

Tabelle 40 : Header-claims des ID_TOKEN des sektoralen IDP

"epk":   {"kty":"EC",
          "crv":"P-256",
          "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
          "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
         }

Die Änderung in der Spezifikation wird mit dem Folgerelease als Korrektur ausgeliefert.

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.

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 - draft 36 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 2024 zu veröffentlichen.