latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Identity Provider-Dienst

    

     

      
Version
      
1.6.0
     
     

      
Revision
      
872746
     
     

      
Stand
      
15.03.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_Dienst
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Identity Provider (IDP)-Dienst. Der IDP-Dienst basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Die hier beschriebenen Schnittstellen werden vom Authenticator-Modul und vom Anwendungsfrontend für eine Authentifizierung eines Nutzers anhand einer Smartcard genutzt. Diese Authentifikation ist die Voraussetzung, damit ein Nutzer über das Anwendungsfrontend Zugang zu Fachdaten eines Fachdienstes erlangen kann. Der IDP-Dienst verwaltet und steuert den Smartcard-basierten Authentifizierungsprozess für verschiedene Anwendungen und stellt diesen nach erfolgter Authentisierung ein ID_TOKEN mit den Identitätsdaten des Nutzers bereit.

Darüber hinaus agiert der IDP-Dienst auch als OAuth2 Authorization-Server für das E-Rezept und stellt in dieser Funktion über die reine Authentisierung hinaus mittels ACCESS_TOKEN auch die Authorisierung der Zugriffe eines Anwendungsfrontend auf den E-Rezept-Fachdienst sicher.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Identity Providern, welche die Funktionen des IDP-Dienstes der gematik realisieren wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur (TI) des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Nicht Bestandteil des vorliegenden Dokumentes sind die Verfahrensschritte zur Erstellung des notwendigen Schlüsselmaterials. Es wird angenommen, dass Fachdienste ihre innerhalb der TI zu verwendenden Zertifikate für die Transport Layer Security (TLS)-Sicherung über zentrale Plattformdienste der TI beziehen und diese dort auch geprüft werden können. Außerhalb des TI-Netzes können TLS-Zertifikate von den Mitgliedern des CA/Browser Forum als übliche Anbieter solcher Zertifikate bezogen werden. Diese sind über Standardmechanismen prüfbar und erfordern keine besondere Behandlung der PKI. Wenn notwendig werden weitere Schutzmechanismen wie Zertifikat-Pinning, Certification Authority Authorization (CAA) Records oder ein Monitoring mittels Certificate Transparency (CT) vorgesehen.

Als Umsetzungsleitlinie ist [OpenID Connect Core 1.0] heranzuziehen. Die TI-weit übergreifenden Festlegungen – insbesondere aus Dokumenten wie beispielsweise [gemSpec_Krypt] bezüglich Algorithmen und Schlüsselstärken sowie [gemSpec_PKI] bezüglich zu verwendender Zertifikatstypen und deren Attributausprägungen – haben Bestand, sind weiterhin bindend und werden nicht in diesem Dokument beschrieben.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

Hinweise auf offene Punkte

2 Systemüberblick

Im Rahmen der kontinuierlichen Erweiterung der Vorgaben für Identity Provider innerhalb der TI werden  die Vorgaben weiter angepasst werden. Dies beinhaltet Festlegungen zur Einführung föderierter Identity Provider, die Unterstützung weiterer Anwendungen und Nutzungsszenarien, Vorgaben für zulässige Authentisierungsverfahren, Schnittstellen für die Inter-App-Kommunikation zu einer getrennten Authenticator-Anwendung sowie die mögliche Einführung weiterer Endpunkte entsprechend [openid-connect-core]. 

2.1 Allgemeiner Überblick

In der Telematikinfrastruktur werden zahlreiche Fachdienste angeboten. Anwendungsfrontends können über die Authentifizierung des Nutzers am IDP-Dienst Zugriff zu den von den Fachdiensten für diesen Nutzer angebotenen Daten erhalten. Der IDP-Dienst stellt durch gesicherte JSON Web Token (JWT) attestierte Identitäten bereit.

Dabei erfüllt der IDP-Dienst zwei unterschiedliche Rollen

1.) Authorization-Server für das E-Rezept

Gegen Vorlage eines ACCESS_TOKEN, des für die Fachanwendung zuständigen Authorization-Server, erhalten Anwendungsfrontends – entsprechend der im Token attestierten Parameter – Zugriff auf die Inhalte des Fachdienstes. Der IDP-Dienst erfüllt diese Funktion für den E-Rezept-Fachdienst und stellt dabei den verschiedenen Anwendungsfrontends (Primärsysteme in Praxen und Apotheken sowie die E-Rezept App) zeitlich begrenzte ACCESS_TOKEN für den Zugang aus. In dieser Funktion bindet der IDP-Dienst für die Authentisierung von Versicherten auch weitere Identity Provider an, welche im Rahmen der TI-Föderation verschiedene Verfahren für die Anmeldung des Nutzers bieten. Die Versicherten können auf diesem Weg mit demselben Authentisierungsverfahren auf verschiedene Anwendungen der TI und ihrer Krankenkasse zugreifen.

2.) Identity Provider

Der IDP-Dienst übernimmt darüber hinaus für verschiedene Fachdienst die Aufgabe der smartcard-basierten Authentisierung des Nutzers. Der IDP-Dienst fasst eine eindeutige IdNummer sowie weitere für den Fachdienst notwendige Attribute in signierten JSON Web Token (ID_TOKEN) zusammen. Fachdienste müssen so keine Überprüfung des Nutzers selbst implementieren, sondern können sich darauf verlassen, dass der Besitzer des bei ihnen vorgetragenen ID_TOKEN bereits authentisiert wurde. Des Weiteren stellt der IDP-Dienst sicher, dass die vom Nutzer vorgetragenen Attribute (aus dem Signaturzertifikat einer Smartcard) gültig sind.

Der IDP-Dienst prüft in dieser Funktion, ob das in einem Challenge-Response Prozess vorgetragene X.509-nonQES-Signatur-Zertifikat der verwendeten Prozessor-Chipkarte (eGK, HBA oder SMC-B) zeitlich gültig und ob seine Integrität sichergestellt ist.

Der IDP-Dienst stellt dann ID_TOKEN für den anfragenden Fachdienst aus, welche auf den Inhalten der gültigen AUT-Zertifikate (d.h. C.CH.AUT, C.HP.AUT oder C.HCI.AUT) basieren.

2.2 Detaillierter Überblick

Der IDP-Dienst führt die Identifikation des Nutzers durch und stattet diesen mit einem ID_TOKEN gemäß [openid-connect-core 1.0 # IDToken], einem ACCESS_TOKEN gemäß [RFC6749 # section-1.4] oder ggf. einem SSO_TOKEN basierend auf [RFC7519] aus. Gewählt wird für alle Prozesse aus Sicherheitsaspekten der Authorization Code Grant gemäß [RFC6749 # section-4.1].  Die Verwendung von PKCE (Proof Key for Code Exchange by OAuth Public Clients) gemäß [RFC7636] wird gefordert.

Der IDP-Dienst teilt sich in mehrere Teildienste auf. Einzelne Teildienste werden zentral und bei Bedarf auf unterschiedlicher Hardware verteilt betrieben. Das Authenticator-Modul wird grundsätzlich auf dezentraler Hardware zusammen mit dem Primärsystem oder auf dem mobilen Endgerät des Nutzers betrieben. Der IDP-Dienst stellt unterschiedliche Endpunkte bereit, welche eine statische IP-Adressierung und somit statische URI besitzen. Diese statisch adressierten Endpunkte umfassen:

• Discovery-Endpunkt ("OAuth 2.0 Authorization-Server Metadata" [RFC8414])
  
• Redirection-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749 # section-3.1.2 ])

• Authorization-Endpunkt (Teil des "The OAuth 2.0 Authorization Framework" [RFC6749])

• Token-Endpunkt ([RFC6749 # section-3.2])
  Teildienst 1 ID_TOKEN ([openid-connect-core 1.0 # IDToken])
  Teildienst 2 ACCESS_TOKEN ([RFC6749 # section-1.4 & RFC6749 # section-5])
  

Im folgenden Schaubild sind die vom IDP-Dienst bereitgestellten Teildienste blau hinterlegt.

Teildienste wie das Authenticator-Modul und das Anwendungsfrontend befinden sich in dem mit "Gerät des Nutzers" bezeichneten Bereich.

Fachdienste sind nicht näher bestimmt und befinden sich im Block unterhalb des Identity Providers.

Abbildung 1: Übersichtsschaubild OAuth2.0 IdP-Dienst

Erläuterungen zur obigen Abbildung:
Die Teilschritte (1) und (5) werden bei mobilen Endgeräten (FdV) via Redirection-Endpunkt [RFC6749 # section-3.1.2] realisiert.
Die Teilschritte (1) und (5) können bei Primärsystemen (PVS, AVS, KVS) abweichend von [RFC6749 # section-9] behandelt werden.
Die Teilschritte (2) und (4) werden durch den Authorization-Endpunkt gemäß [RFC6749 # section-3.1] bedient.
Der Teilschritt (3) Challenge-Response wird durch den Authorization-Endpunkt bedient.
Die Teilschritte (6) und (7) werden durch den Token-Endpunkt [RFC6749 # section-3.2] bedient.

Der hier gezeigte IDP-Dienst stellt eine Basisleistung innerhalb der TI dar und soll die sichere Identifikation der Akteure anhand der ihnen bereitgestellten Identifikationsmittel (Smartcards) ermöglichen. Der Standard lässt hierbei die Einbringung weiterer Identity Provider für unterschiedlichste Identifikationsverfahren zu, ohne dass Fachdienste hierfür eine Änderung der Zugangsmechanismen realisieren müssen.

Die Umsetzung basiert grundsätzlich auf [OpenID Connect Core v1.0] und [OpenID Connect Discovery v1.0].

Weitere zu beachtende Standards sind die folgenden:
Request for Comments JWT (JSON Web Token) [RFC7519 ], JWS (JSON Web Signature) [RFC7515 ], JWE (JSON Web Encryption) [RFC7516 ], JWK (JSON Web Key) [RFC7517 ], JWA (JSON Web Algorithm) [RFC7518] und WebFinger [RFC7033] sowie OAuth 2.0 Bearer [RFC6750], OAuth 2.0 Assertion [RFC7521], OAuth 2.0 JWT Profile [RFC7523], OAuth 2.0 Responses [RFC6749 ].

Die Gesamtliste der referenzierten Standards finden sich im Abschnitt 6.5.2 Weitere Dokumente.

3 Systemkontext

Die untere Abbildung beschreibt den Systemkontext aus Sicht des IDP-Dienstes. Das Authenticator-Modul liefert die Daten zur Authentifizierung des Nutzers an den IDP-Dienst. Bei positiver Validierung – gegen den OCSP/TSL-Dienst der Public Key Infrastructure (PKI) der gematik – liefert der IDP-Dienst einen AUTHORIZATION_CODE zurück. Der IDP-Dienst liefert ebenso einen SSO_TOKEN, wodurch das Authenticator-Modul einen weiteren AUTHORIZATION_CODE ohne erneute Nutzerauthentifizierung erhalten kann. Das SSO-Token kommt nur beim E-Rezept FdV zum Einsatz und erfüllt hier die Funktion eines Refresh-Token.

Das Anwendungsfrontend registriert sich innerhalb eines organisatorischen Prozesses am IDP-Dienst. Das Anwendungsfrontend erlangt gegen Vorlage des AUTHORIZATION_CODE einen ID_TOKEN und einen ACCESS_TOKEN. Das Anwendungsfrontend erhält gegen Vorlage des ACCESS_TOKEN Zugang zu den Fachdaten des Fachdienstes.

Der Fachdienst registriert sich am IDP-Dienst in Form eines organisatorischen Prozesses.

Abbildung 2: Systemkontext aus Sicht des IDP-Dienstes

3.1 Akteure und Rollen

Im Systemkontext des IDP-Dienstes interagieren verschiedene Akteure (Nutzer und aktive Komponenten) in unterschiedlichen OAuth2-Rollen gemäß [RFC6749 # section-1.1].

Tabelle 1: TAB_IDP_DIENST_0001 Akteure und OAuth2-Rollen

Nutzer (Rolle: Resource Owner)

Der Resource Owner ist der Nutzer, welcher auf die beim Fachdienst (Resource Server) für ihn bereitgestellten Daten (Protected Resource) zugreift.

Der Resource Owner verfügt über die folgenden Komponenten:

·         Endgerät des Nutzers

·         Authenticator-Modul

·         Anwendungsfrontend

Fachdienst (Rolle: Resource Server)

Der Resource Server ist der Fachdienst, der dem Nutzer (Resource Owner) Zugriff auf seine Fachdaten (Protected Resource) gewährt. Der Fachdienst, der die geschützten Fachdaten (Protected Resources) anbietet, ist in der Lage, auf Basis von ACCESS_TOKEN Zugriff für Clients zu gewähren. Ein solches Token repräsentiert die delegierte Identifikation des Resource Owners.

Anwendungsfrontend/Authenticator-Modul kombiniert in einer Applikation (Rolle: Client)

Der Client  greift mit dem Authenticator-Modul und dem Anwendungsfrontend (OIDC Relying Party bzw. OAuth2 Client) auf  Fachdienste (Resource Server) und ihre geschützten Fachdaten (Protected Resource) zu. Das Anwendungsfrontend kann auf einem Server als Webanwendung (Primärsystem als Terminalserver), auf einem Desktop-PC oder einem mobilen Gerät (z.B. Smartphone) ausgeführt werden.

IDP-Dienst (Rolle: Authorization-Server)

Der Authorization-Server authentifiziert den Resource Owner (Nutzer) und stellt ID_TOKEN, ACCESS_TOKEN und SSO_TOKEN für den vom Resource Owner erlaubten Anwendungsbereich (SCOPE) aus, welche dieser wiederum beim Fachdienst einreicht.

Tabelle 2: TAB_IDP_DIENST_0002 Kurzbezeichnung der Schnittstellen des IDP-Dienstes

Weitere Akteure im Kontext IDP-Dienst sind:

Fachdaten (Rolle: Protected Resource)

Die geschützten Fachdaten, welche vom Fachdienst (Resource Server) angeboten werden.

3.2 Begriffsdefinition

Die folgende Tabelle enthält die Abkürzungen (für die privaten Schlüssel PrK und für öffentliche Schlüssel PUK) der verschiedenen Endpunkte des IDP-Dienstes und deren Verwendung.

Tabelle 3: TAB_IDP_DIENST_0003 Bezeichnungen der extern genutzten Schlüssel und Adressen des IDP-Dienstes

 
Hinweis: Werden alle Teildienste auf einem Server gemeinsam betrieben, so können diese dasselbe Schlüsselmaterial verwenden. Werden Teildienste auf unterschiedlichen physischen oder logischen Servern betrieben, so sind die Endpunkte mit eigenem Schlüsselmaterial auszustatten.

Die URL des Discovery Document URI_DISC stellt somit den zentralen Anlaufpunkt dar, anhand dessen alle weiteren „statischen“ Dienste (Endpunkte des IDP-Dienstes) adressiert werden können.

Hinweis: Bei allen extern genutzten Schlüsseln handelt es sich um ECC-Schlüsselpaare der Kurve brainpoolP256r1. Für IDP_ENC ist im Gegensatz zu den anderen beiden Schlüsseln keine Bestätigung als Zertifikat vorgesehen. Die maximale Einsatzdauer des Schlüsselpaares liegt analog zum IDP_SIG und DISC_SIG bei maximal 5 Jahren.

3.3 Verfahrensbeschreibung

Vorbereitende Maßnahmen: Das Anwendungsfrontend und der Fachdienst haben sich im Zuge eines organisatorischen Prozesses beim IDP-Dienst registriert. Das Anwendungsfrontend und das Authenticator-Modul haben das Discovery Dokument eingelesen und kennen damit die Uniform Resource Identifier (URI) und die öffentlichen Schlüssel der vom IDP-Dienst angebotenen Endpunkte. Der Fachdienst hat bei der Registrierung am IDP-Dienst seinen öffentlichen Schlüssel hinterlegt.

Abbildung 3: Datenfluss-Diagramm IDP-Dienst

Die Prozessschritte, welche notwendig sind, damit ein mobiles Anwendungsfrontend einen Token erhält sind:

1. Das Anwendungsfrontend erzeugt sich einen CODE_VERIFIER [RFC7636 # section-4.1] und bildet darüber den Hash CODE_CHALLENGE mit dem Hash-Algorithmus S256 gemäß [RFC 7636 # section-4.2].
2. Das Anwendungsfrontend überträgt seinen Authorization Request inklusive der generierten Werte  CODE_CHALLENGE, State und Nonce gemäß [RFC8252 # Anhang B] an das Authenticator-Modul.
3. Das Authenticator-Modul überträgt den Authorization Request weiter an den Authorization-Endpunkt des IDP-Dienstes.
   
4. Der Authorization-Endpunkt prüft die Inhalte des Authorization Request wie etwa die ClientID.
5. Der Authorization-Endpunkt stellt alle Informationen zusammen und erzeugt die CHALLENGE.
6. Der Authorization-Endpunkt stellt den mit dem entsprechenden Fachdienst vereinbarten Consent (Zustimmung des Nutzers zur Verarbeitung der angezeigten Daten) zusammen.
7. Der Authorization-Endpunkt überträgt CHALLENGE_TOKEN und Consent-Abfrage USER_CONSENT zum Authenticator-Modul.
8. Das Authenticator-Modul fordert den Nutzer zu Consent-Freigabe auf mittels Smartcard und PIN-Eingabe. Falls bereits ein SSO_TOKEN beim Authenticator-Modul existiert, entfällt dieser Schritt.
9. Das Authenticator-Modul verwendet die PIN um die CHALLENGE_TOKEN von der Smartcard signieren zu lassen. Falls bereits ein SSO_TOKEN beim Authenticator-Modul existiert, entfällt dieser Schritt.
10. Das Authenticator-Modul überträgt das signierte CHALLENGE_TOKEN mit dem Smartcard-Zertifikat, verschlüsselt mittels PuK_IDP_ENC, an den IDP-Dienst (Antwort Schritt 7). Falls ein SSO_TOKEN beim Authenticator-Modul existiert, wird dieser Token zusammen mit einem unveränderten CHALLENGE_TOKEN zum IDP-Dienst transportiert.
    
11. Der Authorization-Endpunkt entschlüsselt und validiert die signierte Challenge. Die Signatur wird anhand des im "x5c"-Header mitgelieferten Authentifizierungszertifikats der Smartcard validiert. Falls ein SSO_TOKEN angenommen wurde, wird dieses validiert. Entschlüsselt wird das SSO_TOKEN vom Authorization-Endpunkt mit seinem Schlüsselmaterial, welches er zur Verschlüsselung genutzt hat. Die Überprüfung der Signatur des SSO_TOKEN führt der Authorization-Endpunkt anhand seines öffentlichen Schlüssels PuK_IDP_SIG durch.
12. Der Authorization-Endpunkt erstellt den AUTHORIZATION_CODE.
13. Der Authorization-Endpunkt überträgt den AUTHORIZATION_CODE und den SSO_TOKEN an das Authenticator-Modul (Antwort Schritt 3). Falls das Authenticator-Modul ein vorhandenes SSO_TOKEN an den Authorization-Endpunkt zur Erlangung eines AUTHORIZATION_CODE geschickt hat, wird kein neues SSO_TOKEN vom Authorization -Endpunkt erstellt und verschickt. Der AUTHORIZATION_CODE und das SSO_TOKEN werden vom Authorization-Endpunkt mit seinem privaten Schlüssel PrK_IDP_SIG signiert. Der Authorization-Endpunkt verschlüsselt das SSO_TOKEN für sich und den AUTHORIZATION_CODE für den Token-Endpunkt. Das zur Verschlüsselung verwendete Schlüsselmaterial muss die Vorgaben der [gemSpec_Krypt] beachten.
    
14. Das Authenticator-Modul überträgt den AUTHORIZATION_CODE an das Anwendungsfrontend (Antwort Schritt 2).
15. Das Anwendungsfrontend erzeugt sich einen AES256-"Token-Key", verknüpft ihn mit dem CODE_VERFIER zum KEY_VERIFIER und sendet diesen unter Nutzung des öffentlichen Schlüssels PUK_IDP_ENC verschlüsselt zusammen mit dem AUTHORIZATION_CODE zum Token-Endpunkt des IDP-Dienstes.
16. Der Token-Endpunkt entschlüsselt den AUTHORIZATION_CODE und validiert ihn anhand des öffentlichen Schlüssels PUK_IDP_SIG des Authorization-Endpunktes. 
17. Der Token-Endpunkt entschlüsselt und validiert den KEY_VERIFIER, entnimmt aus diesem den CODE_VERIFIER und gleicht diesen mit der CODE_CHALLENGE aus dem AUTHORIZATION_CODE ab.
18. Der Token-Endpunkt erzeugt die erforderlichen Token, signiert sie mit seinem privaten Schlüssel PrK_IDP_SIG und verschlüsselt sie mit dem „Token-Key“ des Anwendungsfrontend, welchen er dem KEY_VERIFIER entnimmt.
19. Der Token-Endpunkt überträgt die Token an das Anwendungsfrontend (Antwort Schritt 16).
    
20. Das Anwendungsfrontend entschlüsselt die Token mit seinem „Token-Key“ und prüft die Token-Signatur anhand des öffentlichen Schlüssels PUK_IDP_SIG des Token-Endpunktes.
21. Das Anwendungsfrontend reicht das gültige ACCESS_TOKEN auf Anwendungsebene verschlüsselt beim Fachdienst ein.
22. Der Fachdienst entschlüsselt das ACCESS_TOKEN entsprechend dem für diese Anwendung vorgesehenen Verfahren.
23. Der Fachdienst validiert das ACCESS_TOKEN anhand des öffentlichen Schlüssels PUK_TOKEN des Token-Endpunktes.
24. Der Fachdienst zieht die Claims (d. h. die Key/Value-Paare im Payload eines Tokens) aus dem ACCESS_TOKEN und gibt bei positiver Validierung den Zugriff auf die Fachdaten frei.

Hinweis: Verwendet der Nutzer ein Primärsystem, führt der Konnektor in Schritt 9 die Funktion "externalAuthenticate" für eine Signatur mit der SMC-B durch. Setzt der Nutzer ein mobiles Endgerät ein, ruft das Authenticator-Modul die Signaturfunktion eines HBA oder einer eGK für eine nonQES-Signatur der Smartcard auf. Die erforderlichen Token in Schritt 19 sind ID_TOKEN und ACCESS_TOKEN. Das Authenticator-Modul kann mit dem SSO_TOKEN einen neuen AUTHORIZATION_CODE beim IDP-Dienst ohne erneute Nutzer-Authentifizierung anfordern und damit ein neues ACCESS_TOKEN vom IDP-Dienst erhalten. Das SSO_TOKEN erfüllt hier für das E-Rezept-FdV die Funktion eines Refresh-Token. Im SSO_TOKEN hinterlegt der IDP-Dienst die für ihn selbst bestimmten Informationen zum gesamten Vorgang, sodass er keine schützenswerten Informationen zentral speichern muss. Das SSO_TOKEN beinhaltet alle Daten, die beim IDP-Dienst benötigt werden, um auf die Vorgangshistorie zurückzugreifen und ggf. neue ACCESS_TOKEN herauszugeben. Die Informationen im SSO_TOKEN sind mit dem öffentlichen Schlüssel des Authorization-Endpunktes für diesen selbst verschlüsselt und können ausschließlich mit dem privaten Schlüssel des Authorization-Servers wieder entschlüsselt werden.

Im Schaubild Datenflussdiagramm IDP-Dienst oben ist der Datenfluss zwischen Anwendungsfrontend, Authenticator-Modul, IDP-Dienst und Fachdienst dargestellt. Der Datenfluss weicht im Falle von Primärsystemen hiervon ab, wenngleich Primärsysteme ebenfalls Nutzer-Endgeräte sind. Die Abweichung des Datenflusses wird im nächsten Kapitel erläutert.

3.4 Abweichende Verfahrensbeschreibung für Primärsysteme

Da bei Primärsystemen der Zugriff auf das Authenticator-Modul nicht in allen Fällen in Form eines Links innerhalb des Systems erfolgen kann, muss von der Vorgehensweise für mobile Endgeräte des Nutzers abgewichen werden. Das Primärsystem hat nicht die Möglichkeit, die Anfrage zum freizugebenden Consent anzuzeigen und nicht zur Eingabe der PIN aufzufordern. Zum Betrieb des Primärsystems ist es notwendig, dass sich die SMC-B im freigeschalteten Modus befindet. Damit muss die Freischaltung der SMC-B genutzt werden, um die Consent-Freigabe dauerhaft zu bestätigen und die vom IDP-Dienst in Schritt 6 geforderte Challenge ohne PIN-Eingabe zu realisieren.

Für die Signatur der Challenge wird die Funktion "externalAuthenticate" des Konnektors verwendet, welcher diesen Funktionsaufruf nur von den Primärsystemen entgegennimmt, an welchen ein Mitarbeiter der Praxis aktiv eingeloggt ist.

3.5 Registrierung Anwendungsfrontend und Fachdienst

Um ein Anwendungsfrontend nutzen zu können, muss dieses beim IDP-Dienst registriert sein. Die Registrierung des Anwendungsfrontends ist im Dokument [gemSpec_IDP_Frontend] beschrieben.

Anbieter von Fachdiensten müssen ebenfalls die Registrierung ihres Fachdienstes über einen organisatorischen Prozess beim IDP-Dienst durchführen.

Ergänzung: Diese Registrierung erfolgt einmalig für die Anwendung bzw. den Dienst und muss bei Updates nicht wiederholt werden. Die Registrierung des Fachdienstes beinhaltet dabei auch die Abstimmung der Claims und die Gültigkeitsdauer der erstellten Token (siehe [gemSpec_IDP_FD#Kapitel 4]), wobei der Fachdienst seinen Bedarf an den gewünschten Attributen erklärt. Anpassungen an den Claims bedürfen einer erneuten Abstimmung und Registrierung.

3.6 Anwendungsfrontend vorbereitende Maßnahmen

Das Anwendungsfrontend muss einen CODE_VERIFIER (Zufallswert) gemäß [RFC7636 # section-4.1] und hierüber einen Hash, die CODE_CHALLENGE, gemäß [RFC7636 # section-4.2] mit dem Algorithmus S256 gemäß [RFC7636 # section-4.2] erzeugen.

3.7 Anfrage von Token

Die folgende Anfrage an den Authorization-Endpunkt umfasst die Schritte 1-3 aus dem Gesamtablauf des Kapitels 3.3. Der Request wird hierbei entweder vom Anwendungsfrontend (Funktion Authorization-Server) oder dem Fachdienst (Funktion Identity Provider) generiert. Die Adressierung des IDP-Dienstes ist als Parameter in einer Konfigurationsdatei oder direkt im Quellcode hinterlegt.

Die Anfrage wird dann über das Authenticator-Modul an den Authorization-Endpunkt des IDP-Dienstes geleitet.

Inhalt der Anfrage ist:

• die redirect_uri sowie der Scope (Attributsumfang) der Anfrage,
• Die client_id als Identifikation des Anfragenden Systems
• die eigene Hersteller-ID, Programmkürzel und Versionsnummer,
• der über den eigenen CODE_VERIFIER [RFC7636 # section-4.1] gebildete Hash code_challenge [RFC7636 # section-4.2] mit Angabe des Algorithmus code_challenge_method [RFC7636 # section-4.3],
• der state-Parameter [RFC8252 # section-8.9] wird genutzt, um CSRF (Cross-Site-Request-Forgery) zu verhindern.
• der nonce-Parameter openid-connect-core#Authentication Request] kann zusätzlich genutzt werden um den Erhalt des korrekten ID_TOKEN zu verifizieren.

Details siehe 7.1 Authorization Request.

3.8 Aufgaben des Authorization-Endpunktes

Der Authorization-Endpunkt nimmt die Anfrage an und überprüft ob client_id und scope bekannt und in dieser Kombination zulässig sind

3.8.1 Erstellung des AUTHORIZATION_CODE

Im Fall einer Authentisierung mittels Smartcard sendet der Authorization-Endpunkt eine CHALLENGE an das Authenticator-Modul und prüft anschließend die Signatur der CHALLENGE und das mitgelieferte Zertifikat der Smartcard des Nutzers mittels OCSP/TSL der PKI der Telematikinfrastruktur, bevor er die benötigten Attribute ausliest.

Wenn der IDP-Dienst als Authorization-Server für das E-Rezept agiert, kann er alternativ einen eigenen Request an den durch den Nutzer gewählten sektoralen Identity Provider formulieren und bekommt von diesem nach erfolgter Authentisierung des Nutzers ein ID_TOKEN ausgestellt, welchem er die Attribute entnimmt.

Sind alle im Claim geforderten Attribute vorhanden und die Gültigkeit der Attribute geprüft, erstellt der Authorization-Endpunkt einen AUTHORIZATION_CODE und sendet diesen an das Anwendungsfrontend.

3.9 Einreichen des AUTHORIZATION_CODE

Das Anwendungsfrontend reicht den AUTHORIZATION_CODE zusammen mit dem CODE_VERIFIER beim Token-Endpunkt ein.

3.10 Aufgabe des Token-Endpunktes

Der Token-Endpunkt des IDP-Dienstes nimmt die Anfrage des Anwendungsfrontends bzw. Fachdienstes entgegen und prüft neben deren Integrität, ob der eingereichte CODE_VERIFIER bei Nutzung des Hash-Verfahrens S256 (nach [RFC7636 # section-4.2]) zum bitgleichen Hash-Wert führt. Stimmt der Hash-Wert aus dem initialen Aufruf des Authenticator-Moduls - die CODE_CHALLENGE - mit dem gebildeten Hash-Wert überein, ist sichergestellt, dass Aufrufer und Initiator identisch sind. Der Token-Endpunkt gibt daraufhin das ID_TOKEN / ACCESS_TOKEN an das anfragende System heraus.

3.11 Einreichen des ACCESS_TOKEN beim Fachdienst

Um schlussendlich Zugriff auf den Fachdienst zu bekommen, reicht das Anwendungsfrontend das ACCESS_TOKEN beim Fachdienst ein.

3.12 Aufgabe des Fachdienstes

Wenn der IDP_Dienst als Authorization-Server agiert, nimmt der Fachdienst das zwischen Frontend und Fachdienst anwendungsspezifisch verschlüsselte ACCESS_TOKEN entgegen. Danach überprüft er die Integrität und die Übereinstimmung mit den benötigten Claims. Enthält das ACCESS_TOKEN mehr oder weniger Attribute, als im Scope vereinbart, oder sind diese fehlerhaft befüllt, stimmt die Integrität oder Signatur des ACCESS_TOKEN nicht oder ist das ACCESS_TOKEN zeitlich nicht mehr gültig, bricht der Fachdienst die Kommunikation mit einer dem Abbruchgrund entsprechenden Fehlermeldung ab.

Bei positiver Validierung gewährt der Fachdienst Zugriff auf seine Fachdaten.

Wenn der IDP-Dienst als reiner Identity Provider agiert, so verwendet der Fachdienst den ID_TOKEN zur Identifikation des gegenüber dem IDP-Dienst authentisierten Nutzer.

Hierbei können auch ACCESS_TOKEN eines eigenen Anwendungsspezifischen Authorization-Server zum Einsatz kommen.

4 Zerlegung des Produkttyps

Der Produkttyp besteht aus einer zentralen Komponente (IDP-Dienst). Diese wird bei der Durchführung des Authentifizierungsprozesses vom Authenticator-Modul unterstützt. Das Authenticator-Modul übernimmt die Ausführung der Nutzerauthentisierung. Bei Verwendung eines stationären Endgerätes mit installiertem Primärsystem, realisiert das Primärsystem die Funktionalität des Authenticator-Moduls. Das Anwendungsfrontend ist ebenso als Teil des Primärsystems realisiert. Bei Verwendung eines mobilen Endgeräts, ist dort sowohl das Authenticator-Modul, als auch das Anwendungsfrontend gemeinsam in einer Applikation installiert. 

Der IDP-Dienst stellt die zentralisierte Identitätsprüfung der auf die Fachdienste zugreifenden Nutzer bereit. Als weitere Teile der Gesamtlösung sind neben dem IDP-Dienst die Clients (Anwendungsfrontend/Primärsystem) und die Fachdienste zu nennen, auf denen Fachdaten für den Zugriff durch die Nutzer (z. B. Versicherte oder Bediener eines AVS, PVS oder KVS) bereitgestellt werden. Ein IDP-Dienst bietet Fachdiensten seine Dienste an, auf welche Millionen Nutzer zeitgleich zugreifen. Eine wesentliche Ergänzung des IDP-Dienstes ist das Authenticator-Modul, welches auf den dezentralen Komponenten in den Praxen, Kliniken, Apotheken und bei den Versicherten betrieben wird.

Hinweis: Die Bereitstellung von öffentlichem Schlüsselmaterial bezieht sich auf die Schlüssel zum Signieren und ggf. Verschlüsseln der JSON Web Token. Hiermit sind nicht die öffentlichen Schlüssel der TLS-Verschlüsselung gemeint.

4.1.1 Allgemeine Sicherheitsanforderungen

4.1.2 Sicherheit der Netzübergänge

Der IDP-Dienst wird für Versicherte über das Internet erreichbar gemacht und für Leistungserbringer über das Netz der TI. Die folgenden Anforderungen beschreiben die für diese Netzübergänge erforderlichen Sicherheitsmechanismen. Für den Netzübergang aus dem Internet als Transportnetz zum IDP-Dienst ist ein Paketfilter erforderlich.

Hinweis: Durch die Zurückweisung von Verbindungen wird sichergestellt, dass Clients einen Verbindungsaufbau mit einer anderen Instanz des Fachdienstes versuchen, bei dem die erforderlichen Ressourcen zur Verfügung stehen.

4.2 Fehlermeldungen

4.3 Schnittstellenbeschreibung des IDP-Dienstes

Der IDP-Dienst bietet zahlreiche Schnittstellen gegenüber unterschiedlichen Akteuren inner- und außerhalb der TI an, weswegen es notwendig ist, die einzelnen Schnittstellen so zu beschreiben, dass andere Akteure deren Funktionsweise leichter verstehen können. Nachfolgende Abbildung skizziert die Schnittstellen des IDP-Dienstes. Komponenten und Schnittstellen, welche nicht direkt vom IDP-Dienst genutzt werden, sind in der Abbildung grau hinterlegt.

Abbildung 4: Schnittstellen des IDP-Dienstes

Die erste tokenbezogene Anfrage an den Authorization-Server des IDP-Dienstes geht am Authorization-Endpunkt [RFC6749 # section-3.1] ein. Das Authenticator-Modul reicht dort am Endpunkt den CONSENT mit der CHALLENGE ein, mit welchem die TOKEN erstellt werden sollen, und erhält den AUTHORIZATION_CODE zurück, falls die Prüfung der signierten CHALLENGE und die Prüfung des übergebenen Smartcard-Zertifikats am OCSP/TSL-Dienst positiv ausfallen. Das Anwendungsfrontend reicht den AUTHORIZATION_CODE am Token-Endpunkt [RFC6749 # section-3.2] des IDP-Dienstes ein. Der IDP-Dienst überprüft den AUTHORIZATION_CODE und stellt bei positiver Validierung einen ID_TOKEN und einen ACCESS_TOKEN aus.

Bei der ersten Kontaktaufnahme erzeugt der Authorization-Server die SUBJECT_SESSION, welche im weiteren Verlauf als Zeitpunkt der letzten Authentisierung gegen die eGK oder den HBA gewertet wird. Basierend darauf dürfen weitere ACCESS_TOKEN und SSO_TOKEN für andere Anwendungsfrontends und Fachdienste ausgegeben werden, wenn das jeweils vorliegende Claim durch die dem Authorization-Server vorliegenden Informationen bedient werden kann. Ist der Zeitpunkt der letzten Authentisierung zu lange her oder wird das Authenticator-Modul zum ersten Mal gestartet, muss eine Authentisierung erfolgen.

Hinweise für die Implementierung der Authentifizierung für Primärsystemen werden in [gemILF_PS_eRp] beschrieben. 

Der Vorgang der Authentifizierung gegen die eGK oder den HBA ist nicht Bestandteil dieser Spezifikation, sondern ist im gesonderten Dokument [gemSpec_IDP_Frontend] beschrieben.

4.4 Identifikation des Clientsystems

Der IDP-Dienst verwaltet und steuert den Authentisierungsprozess für das E-Rezept und perspektivisch auch weitere Anwendungen. Damit kommt ihm eine Relevanz in der Gesundheitsversorgung zu, die sich zum einen in einer hohen Verfügbarkeit und zum anderen in einem hohen Angriffspotential widerspiegelt. Zur Unterstützung der betrieblichen Überwachung des IDP-Dienstes wird die Nutzung der im Feld befindlichen Clientsysteme protokolliert. Dabei ist der Zugriff auf die Schnittstellen des IDP-Dienstes nur durch Primärsysteme der Leistungserbringer, sein eigenes Authenticator-Modul und zugelassene E-Rezept-FdVs zulässig. Der E-Rezept-Fachdienst erkennt die Clientsysteme anhand des User-Agent-Header eingehender HTTP-Requests und protokolliert diesen Wert. 

4.5 Unterstützung der Anmeldung mittels sektoraler Identity Provider

Im Rahmen der Zugänglichmachung des E-Rezepts für Versicherte ohne NFC-fähige eGK sollen ab dem 01.01.2022 Kassen-eigene Authentifizierungssysteme an das E-Rezept angebunden werden. Diese werden im Folgenden als sektorale Identity Provider bezeichnet, um sie vom zentralen IDP-Dienst abzugrenzen, welcher die Authentisierung der Nutzer direkt oder indirekt über die eGK realisiert und die bereitgestellten Attribute von dieser ableitet. 

Zur Einbindung eines sektoralen Identity Provider wird der zentrale IDP-Dienst als Authorisation-Server zwischen dem Anwendungsfrontend, den sektoralen Identity Providern und dem E-Rezept Fachdient eingesetzt.

Die Realisierung der ersten Stufe der sektoralen Identity Provider auf dem Vertrauensniveau "substanziell" ist auf den 31.12.2023 befristet. Dies wird mit der Etablierung einer Föderation von Identity Providern abgelöst. Diese erlauben die Authentisierung von Versicherten. Der IDP-Dienst wird in seiner Rolle als Authorization-Server des E-Rezept Fachdienstes in dieser Föderation registriert und leitet Authentisierungsanfragen an diese weiter. Parallel dazu werden die zuvor etablierten Prozesse zur Anbindung der ersten Stufe der sektoralen Identity Provider bis zum Ende ihrer Befristung unterstützt. Die hierfür relevanten Anforderungen werden in diesem Dokument durch den Zusatz - "Befristet -" im Titel der Anforderung kenntlich gemacht.

Die für die Funktion des IDP-Dienstes innerhalb der Föderation notwendigen Anforderungen aus gemSpec_IDP_FD finden sich in seinem Produkttypsteckbrief.

Weitere Aspekte finden sich in den Kapiteln der jeweiligen Endpunkte.

Hinweis: Der sektorale Identity Provider wird bei Zulassung vermerkt und der zentrale IDP-Dienst geht dann im Auftrag der gematik auf diesen zwecks Registrierung zu.

5 Funktionsmerkmale

5.1 Authorization-Server Metadata (Discovery Document)

Der Authorization-Server dient dazu, bestehende Identitäten zu prüfen und das Prüfungsergebnis in einer einheitlichen Form abgestimmt und durch zusätzliche Mechanismen gesichert bereitzustellen. Basis dieser Dienstleistung ist ein vertrauenswürdiges Verzeichnis, aus welchem hervorgeht, an welchen Schnittstellen dieser Dienst oder seine Teildienste erreichbar sind, wie diese Schnittstellen abgesichert sind und woher man die zur Etablierung der gewünschten Sicherheit erforderlichen Materialien beziehen kann. Gemäß dem verwendeten Standard OpenID Connect mit OAuth 2.0 kommen JSON Web Token (JWT), JSON Web Encryption (JWE), JSON Web Signature (JWS) und JSON Web Key (JWK) zum Einsatz.

Um nutzenden Anwendungen eine einheitliche Bezugsquelle für die Adressierung von Schnittstellen zu schaffen, werden die für alle Akteure grundlegenden Schnittstellen im sogenannten Discovery Document zusammengefasst und dort unter der URI_DISC gemäß [RFC8414 "OAuth 2.0 Authorization Server Metadata"] veröffentlicht.

Alle Akteure, welche den IDP-Dienst nutzen wollen, sind angehalten, dieses Discovery Document zu lokalisieren, herunterzuladen, zu prüfen und den Inhalt in den geplanten Betrieb einzubeziehen.

Hinweis 1: Das Discovery Document innerhalb der TI adressiert hierbei die URI der Schnittstellen des IDP-Dienstes innerhalb der TI. Das im Internet bereitgestellte Discovery Document stellt die URI der angebotenen Fachdienste im Internet mit dort auflösbaren Adressen bereit. 

Hinweis 2: Es gibt je ein internes und externes (public) "Discovery Document". Diese unterscheiden sich in den darin angebotenen URI, welche gleichlautend im Host-Anteil auf unterschiedliche Domänen bzw. Top-Level-Domain (TLD) verweisen.

5.1.1 Aufbau des Discovery Documents

Hinweis: Der genaue Aufbau entspricht [gemSpec_IDP_Dienst#Kapitel 7.7 Aufbau des Discovery Document].

5.1.2 Erneuerung des Discovery Documents

Der Authorization-Server muss das Discovery Document mit den Metainformationen zu den Teildiensten mindestens einmal täglich und immer nach Änderungen mit dem PrK_DISC signieren und am mit der gematik vereinbarten Downloadpunkt URI_DISC bereitstellen.

5.1.3 Schutz des Discovery Document

Der Authorization-Server schützt die Integrität des  Discovery Document auf Dateiebene durch eine Signatur und während des Transportes zusätzlich mittels TLS.

Hinweis: Die für die Rolle des IDP-Dienstes vorgesehene professionOID ist in [gemSpec_OID] beschrieben.

5.1.4 Auswahlliste der sektoraler Identity Provider für den Nutzer

5.2 Authorization-Endpunkt

Vorbedingung ist, dass das Authenticator-Modul bereits eine SUBJECT_SESSION mit dem Authorization-Server etabliert, sich das Discovery Document heruntergeladen und dieses erfolgreich ausgewertet hat.

Hinweis: Der angebotene SSO-Endpunkt bzw. die angebotene URI namens sso_endpoint ist nur für die konkrete Übergabe des SSO_TOKEN nutzbar. Alle vorhergehenden Requests, inklusive des Authentication Requests, sind an den Authorization-Server zu richten.

5.2.1 Authorization-Endpunkt Eingangsdaten

Hinweis: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.1 Authorization Request].

Hinweis: Nach [openid-connect-core-1_0.html # AuthRequest] ist es zulässig, dass ein Client mehrere redirect_uri bei der Registrierung hinterlegt. Der IdP-Dienst muss laut der OIDC-Spezifikation prüfen, ob die im Request gelieferte redirect_uri mit exakt einer der hinterlegten redirect_uri übereinstimmt. Die Prüfung muss über eine Simple String Comparison nach [RFC3986 # section-6.2.1] erfolgen.

Hinweis 1: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].

Hinweis 2: Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Hinweis 3: Die Prüfung auf zeitliche Gültigkeit des Challenge-Token nach Entschlüsselung ist hiervon unbenommen. Die geschilderte Vorabprüfung gestattet dem IDP-Dienst, bei Empfang von zeitlich ungültigen Token auf eine Entschlüsselung zu verzichten.

Hinweis: Der genaue Aufbau des vom Authenticator-Modul übertragenen, signierten CHALLENGE_TOKEN findet sich in [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].

Hinweis: Der Authorization-Endpunkt muss damit die im SSO_TOKEN gelieferten Claims überprüfen und einen AUTHORIZATION_CODE für den angefragten Fachdienst ausstellen.

5.2.2 Authorization-Endpunkt Ausgangsdaten

Konnten alle Prüfungen des eingereichten Consent erfolgreich abgeschlossen werden, erstellt der Authorization-Endpunkt ein AUTHORIZATION_CODE ergänzt durch ein SSO_TOKEN.

Der Token-Endpunkt gibt bei Vorlage eines gültigen AUTHORIZATION_CODE einen ACCESS_TOKEN und einen ID_TOKEN heraus. Ein Authorization_Code ist gültig, wenn er   

• authentisch,
• zeitlich gültig
• noch nicht verwendet wurde

und von einem Client verwendet wird, der im Besitz des CODE_VERIFIERS zu der im AUTHORIZATION_CODE eingebetteten CODE_CHALLENGE ist.

Hinweis: Der genaue Aufbau der Antwort und des CHALLENGE_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.2 Authorization Response].

Hinweis: Der Aufbau der Header entspricht [gemSpec_IDP_Dienst#Kapitel 7.4 Authentication Response].

Hinweis: Der genaue Aufbau der Antwort entspricht [gemSpec_IDP_Dienst#Kapitel 7.4 Authentication Response].

5.3 Token-Endpunkt

Am Token-Endpunkt nimmt der Authorization-Server den AUTHORIZATION_CODE, welchen er selbst am Authorization-Endpunkt ausgegeben hat, entgegen. Da beide vom Authorization-Server selbst erstellt wurden, ist deren Prüfung auf Integrität keine besondere Herausforderung. Allerdings muss der Token-Endpunkt beim Einreichen eines AUTHORIZATION_CODE das dabei mit übertragene CODE_VERIFIER verarbeiten, um mittels Vergleich der Hash-Werte die Übereinstimmung des den AUTHORIZATION_CODE einreichenden mit dem ursprünglich authentisierten Client sicherzustellen. Das verwendete Hash-Verfahren ist im Authorization Request anzugeben.

Hinweis: Die Gültigkeitsdauer des AUTHORIZATION_CODE wird im Claim des angesprochenen Fachdienstes definiert.

Hinweis: Die Gültigkeitsdauer des ACCESS_TOKEN wird im Claim des angesprochenen Fachdienstes definiert.

5.3.1 Token-Endpunkt Eingangsdaten

Hinweis 1: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

Hinweis 2: Als Verschlüsselungsalgorithmus für den KEY_VERIFIER ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Hinweis: Der Aufbau des KEY_VERIFIER entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

Hinweis: Der Aufbau des KEY_VERIFIER entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

5.3.2 Token-Endpunkt Ausgangsdaten

Alle vom IDP-Dienst herausgegebenen Informationen müssen mit dem privateKey des jeweiligen Teildienstes signiert sein, da die mit TLS abgesicherte Verbindung nicht in allen Anwendungsszenarien die Integrität der übertragenen Daten gewährleistet.

Hinweis: Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweis 1: Das Vertrauensniveau "gematik-ehealth-loa-high" ist aktuell das einzige LOA das der e-Rezept Fachdienst kennt. Für die zukünftigen föderierten Identity Provider wird es weiter abgestufte Vertrauensniveaus geben.

Hinweis 2: Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweis 3: Die Claims given_name und family_name werden befüllt wenn die Authentisierung nicht durch einen sektoralen IDP der Föderation erfolgte.

Hinweis: Für den E-Rezept-Fachdienst wird beispielsweise der folgende Wert genutzt: "aud" : "erp.zentral.erp.ti-dienste.de".

Hinweis: Zum Aufbau des Signaturheader siehe [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweis: Zum Aufbau des Verschlüsselungs-Header siehe [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweis: Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

5.4 Pairing-Endpunkt

5.4.1 Zielsetzung

Fachdienste der TI erfordern an Frontends der Versicherten in der Regel eine Authentisierung mithilfe der eGK. Während die Authentisierung auf Basis der eGK bei Verwendung von Mobilgeräten gegenüber dem IDP-Dienst im Dokument [gemSpec_IDP_Frontend] dargelegt ist, zielen die in diesem Dokument dargestellten Erweiterungen der IDP-Spezifikationen darauf ab, die Verwendung von alternativen Authentisierungsmitteln zu ermöglichen, die es Nutzern gestatten sich mithilfe eines Mobilgeräts und vom Nutzer lokal selbst gesetzten Authentisierungsmitteln (wie etwa biometrische oder wissensbasierte Faktoren) ohne weitere Verwendung der eGK gegenüber einem Fachdienst zu authentisieren.

Unter alternativen Authentisierungsmitteln werden hierbei solche verstanden, die aus einem bereits etablierten Authentifizierungsmittel – wie etwa der eGK - abgeleitet werden und dieses in äquivalenter Form ersetzen. Unter einer „Ableitung“ wird hierbei eine zeitbeschränkte, unabhängig nachvollziehbare Beziehung zwischen einem vom Nutzer gesetzten Mittel und einem bereits etablierten Mittel verstanden. Alternative Authentisierungsmittel sind funktional dann anwendbar, wenn das ursprünglich etablierte Authentisierungsmittel anwendbar ist; ihr Lebenszyklus endet spätestens mit Ablauf des Authentisierungsmittels, das zur Ableitung verwendet wurde. 

Die zugrundeliegende Konzeption basiert auf der Verwendung von kryptographischen Verfahren in Kombination mit einem geeigneten Endgerät; eine Verwendung von anderen Authentisierungsmitteln gegenüber dem IDP, wie etwa dort hinterlegte Passwörter, ist nicht angestrebt. Grundlage für die kryptographischen Verfahren ist die Erzeugung eines asymmetrischen Schlüsselpaars auf dem Endgerät des Nutzers. Der öffentliche Schlüssel wird mit anderen Metadaten im Rahmen eines Registrierungsprozesses durch den Nutzer mithilfe seiner eGK gegenüber dem IDP-Dienst authentifiziert und am IDP-Dienst zur zukünftigen Authentifizierung des Nutzers registriert. Der zugehörige private Schlüssel wird vom Nutzer in äquivalenter Weise zu dem in [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend] beschriebenen Challenge/Response-Verfahren zur Authentisierung angewendet. Bedingung für die Anwendung ist die erfolgreiche Authentifizierung des Nutzers durch lokal gesetzte Faktoren.  

Die Kombination von öffentlichem Schlüssel und Metadaten wird im Folgenden als "Pairing" bzw. "Pairing-Daten" benannt. Eine Authentisierung auf Basis des zu einem solchen öffentlichen Schlüssel gehörenden privaten Schlüssels wird "Pairing-basierte Authentisierung" genannt. Das Hinterlegen von Pairing-Daten am IDP-Dienst wird als "Registrierung" bezeichnet. Eine Authentifizierung auf Basis der Pairing-Daten wird als "Pairing-basierte Authentifizierung" bezeichnet. Das Gerät in Kombination mit privatem Schlüssel ist das alternative Authentisierungsmittel. Ein Pairing ist "aktiv", wenn es zur Authentifizierung verwendet werden kann. Voraussetzung für die Aktivierung ist die erfolgreiche Registrierung. Unter "Inspektion" durch den Nutzer wird die Möglichkeit zum Abruf der zu diesem Zweck auf seinem Gerät sowie der am IDP-Dienst gespeicherten Daten verstanden. Der Ausschluss eines alternativen Authentisierungsmittels oder Pairings zum Zweck der Authentifizierung wird "Deaktivierung" genannt. Eine Deaktivierung ist Folge einer Löschung des alternativen Authentisierungsmittels, eines vom Benutzer vollzogenen Deregistrierungsprozesses, des Endes der Gültigkeit des zur Etablierung verwendeten Authentisierungsmittels oder eine auf Basis einer Einstufung der Eignung des verwendeten Geräts getroffenen Entscheidung des IDP-Dienstes. Authentisierungsmethoden des Nutzers gegenüber seinem Gerät bzw. einem auf dem Gerät vorhandenen lokalen Nutzeraccount (z. B. durch biometrische Faktoren oder wissensbasierte Faktoren), werden im Folgenden "lokale Authentisierungsmittel", ihre Anwendung "lokale Authentisierung", ihre Prüfung durch das Gerät "lokale Authentifizierung" genannt.

Der Begriff "isolierte Ausführungsumgebung" wird als abstrakter technik-neutraler Oberbegriff für die verschiedenen üblichen Realisierungsformen von auf Geräten verwendeten Schlüsselspeichern verwendet. Sowohl die Terminologie als auch die tatsächlichen Ausprägungen sind leider uneinheitlich. Typische herstellerspezifische Bezeichnungen oder Ausprägungen sind "Trusted Execution Environment", "Secure-Enclave", "StrongBox" oder "Secure-Element". Im Kontext der Einleitung wird hierunter ein geeignet realisierter Schlüsselspeicher verstanden, in dem Schlüssel erzeugt, gespeichert und gelöscht werden, und die Anwendung des Schlüssels (z. B. zum Zweck der Signaturbildung) auf Daten an bestimmte Bedingungen (wie etwa eine Benutzerauthentifizierung) geknüpft ist und der Zugriff auf die Schlüssel als Datenobjekte ausreichend verhindert wird. 

Die erfolgreiche Authentifizierung des Nutzers bei Verwendung von alternativen Mitteln soll an die in der folgenden Tabelle genannten Faktoren gebunden sein. Die dort genannten Anforderungen adressieren die Abwehr von missbräuchlicher Verwendung des alternativen Authentisierungsmittels bei Wegfall, Modifikation, vermuteter oder erkannter Kompromittierung einer dieser Faktoren durch Deaktivierung.

Tabelle 7: TAB_IDP_DIENST_0008 Faktoren und abgeleitete Anforderungen an das System

Eine Durchsetzung der in der Tabelle genannten und weiterer abgeleiteter Anforderungen ist nicht allein durch das Authenticator-Modul als Softwareeinheit auf dem Gerät des Nutzers und dem IDP-Dienst zu realisieren. Dem Authenticator-Modul obliegt die Prüfung auf das Vorliegen einer – gemessen an Einsatzzweck und Stand der Technik – ausreichend sicheren Einsatzumgebung auf dem mobilen Endgerät, insbesondere auf die Realisierung eines in Interaktion mit Gerät und Betriebssystem durchgesetzten, durchgängigen Schutz der kryptographischen Schlüssel im gesamten Lebenszyklus von

• Erzeugung des Schlüsselpaars,
• Speicherung des privaten Schlüssels,
• Verwendung des privaten Schlüssels zur Authentifizierung,
• Löschung oder endgültige Nicht-Verwendbarkeit des privaten Schlüssels.

Anforderungen an die Implementierung des Authenticator-Moduls zielen darauf ab, dem Betriebssystem und Gerät geeignete  Parameter zu setzen, die eine Kompromittierung des kryptographischen Schlüsselmaterials unabhängig von einer Kompromittierung des Authenticator-Moduls oder des Betriebssystems zu verhindern. Komplementär wird der IDP-Dienst durch die Implementierung eines weiteren Endpunkts (dem "Pairing-Endpunkt") erweitert, der dem Nutzer die Möglichkeit zur

• Registrierung seines Gerätes und des alternativen Authentifizierungsmittels,
• Inspektion der von ihm registrierten Daten und Geräte,
• Deregistrierung eines von ihm registrierten Gerätes und des alternativen Authentifizierungsmittels

gibt. Der Authorization-Endpunkt des IDP-Dienstes wird um die

• Authentifizierung des Nutzers auf Basis von registrierten alternativen Authentifizierungsmittels

erweitert. Registrierung und Authentifizierung schließen die Bewertung der Gerätehardware auf Basis der vorliegenden Informationen durch den IDP-Dienst ein. Die eingeschlossene Bewertung ist motiviert durch die vorab beschränkten Möglichkeiten des Authenticator-Moduls zur Bewertung des Gerätes. Sie bietet dem Betreiber des IDP-Dienstes die Möglichkeit zur direkten Intervention bei Bekanntwerden von Sicherheitsmängeln einzelner Gerätetypen und deren gezieltem Ausschluss bei der Registrierung oder zum Zweck der Authentisierung. 

5.4.2 Technisches Konzept

5.4.2.1 Bewertung von Gerätetypen

Die in den folgenden Abschnitten beschriebenen Erweiterungen des IDP-Dienstes nutzen zur Bewertung eines vom Nutzer verwendeten Gerätetyps zum Zeitpunkt der Registrierung und Authentifizierung zwei Listen (in Kombination im Folgenden Block/Allow-Liste genannt): 

• Die Block-Liste enthält Gerätetypen, die nicht für die Authentisierung geeignet sind; ihre Verwendung zum Zweck der Authentisierung ist ausgeschlossen.
• Die Allow-Liste enthält Gerätetypen, die ohne Einschränkung zum aktuellen Zeitpunkt als zum Zweck der Authentisierung uneingeschränkt geeignet angesehen werden. 
• Gerätetypen, die sich weder auf der Block- noch auf der Allow-Liste befinden, erhalten eine Einstufung als bedingt geeignet zum Zweck der Authentisierung. Eine bedingte Eignung setzt eine Einschränkung an die Verwendungszeit des Pairings, die bei Überschreiten eine Deaktivierung des Pairings bewirkt.

Gerätetypen auf diesen Listen werden anhand der Kombination von 

• Herstellername,
• Produktname,
• Modell,
• Betriebssystem und
• Version des Betriebssystems

beschrieben. Die anhand der Listen vorliegende Bewertung ist nicht als statisch anzunehmen, die Bewertung der Eignung erfolgt kontinuierlich auf Basis des Standes der Technik und der allgemeinen Sicherheitspolitik innerhalb der Telematikinfrastruktur. Die Pflege der Datenbasis obliegt dem Anbieter des IDP-Dienstes nach Vorgaben der gematik. 

5.4.2.1.1 Spezifikation

Hinweis: Unter "vorgelegten Informationen" werden hierbei diejenigen verstanden, die vom Authenticator-Modul im Zuge der Registrierung oder der Authentifizierung über die Datenstruktur "Device_Information" an den IDP-Dienst übermittelt werden.

5.4.2.2 Erweiterung des IDP-Dienstes um einen Pairing-Endpunkt

Der IDP-Dienst wird um einen weiteren Endpunkt erweitert, der die folgenden Funktionalitäten anbietet:

• Registrierung von alternativen Authentisierungsmitteln,
• Inspektion der registrierten alternativen Authentisierungsmittel,
• Deregistrierung von alternativen Authentisierungsmitteln.

Der Endpunkt wird "Pairing-Endpunkt" genannt. Der Pairing-Endpunkt wird unter einer dedizierten, im Discovery Document publizierten URI des IDP-Dienstes in gleichartiger Weise wie in [gemSpec_IDP_Dienst], Abschnitt 2.2 beschrieben bereitgestellt. Die Voraussetzung für die Nutzung der am Pairing-Endpunkt oben genannten angebotenen Dienste ist die Vorlage eines gültigen ACCESS_TOKEN wie in [gemSpec_IDP_Dienst] beschrieben.

Im Fall der Registrierungsfunktion muss die Authentifizierung auf Basis der eGK oder eines auf Basis einer eGK-Authentifizierung ausgestellten SSO_TOKEN unter Verwendung eines geeigneten Gerätes erfolgen. Im Fall der Inspektion oder der Deregistrierung sind pauschal alle am IDP-Dienst zugelassenen Authentisierungsmethoden gestattet. Die Verwendung von bereits registrierten alternativen Authentisierungsmitteln und ggf. anderen Geräten ist hier ausdrücklich zugelassen. Alleinige Bedingung ist die Rückführbarkeit auf ein und dieselbe Identität des Nutzers.  

5.4.2.2.1 Spezifikation

5.4.2.3 Daten und Kommunikationsstrukturen

Die zur Kommunikation zwischen Authenticator-Modul und Pairing-Endpunkt bzw. Authorization-Endpunkt in den Anwendungsfällen

• Registrierung
• Authentifizierung
• Inspektion
• Deregistrierung

verwendeten Datenobjekte basieren wie in [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend] auf JSON-Datenstrukturen mit bzw. als JSON Web Signature (JWS)-Objekte und JSON Web Encryption (JWE)-Objekte für Datenobjekte mit kryptographischem Schutz. Das Interaktionsmuster folgt den REST-Paradigmen. Datenobjekte, die Identitätsinformationen des Nutzers beinhalten, werden auf Anwendungsebene verschlüsselt.

5.4.2.4 Nomenklatur Schlüsselmaterial

Tabelle 8: TAB_IDP_DIENST_0009 Nomenklatur Schlüsselmaterial

5.4.2.5 Registrierung von alternativen Authentisierungsmitteln

Die Registrierung von alternativen Authentisierungsmitteln basiert auf folgenden zwei Voraussetzungen:

1. Authentifizierung des Nutzers am IDP-Dienst: Der Nutzer authentifiziert sich über des in [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend] beschriebenen Challenge-Response-Verfahrens unter Nutzung von eGK oder vorliegendem, auf Basis der eGK bezogenem SSO_TOKEN. Hierin eingeschlossen ist die Autorisierung des Authenticator-Moduls durch den Nutzer zur Einrichtung eines alternativen Authentifizierungsmittels. Im Erfolgsfall mündet der Prozess in einem ACCESS_TOKEN für den Pairing-Endpunkt.
2. Lokale Initialisierung des Geräts des Nutzers: Das Authenticator-Modul prüft die Systemumgebung auf das Vorliegen von Voraussetzungen zur Erzeugung und Verwaltung von kryptographischen Schlüsseln, die durch die vorliegende Systemumgebung ausreichend gegen missbräuchliche Verwendung geschützt sind. Im Erfolgsfall erzeugt das Authenticator-Modul über die Betriebssystem-APIs ein Schlüsselpaar. Der öffentliche Schlüssel und andere Metadaten werden vom Nutzer mit Hilfe der eGK durch eine Signatur authentifiziert. 

Unter einem ausreichend vorhandenen Schutz wird hierbei eine Systemumgebung verstanden, die den Anforderungen der Kapitel [gemSpec_IDP_Frontend#Kapitel "Parameter für die Schlüsselerzeugung und Auswahl eines Schlüsselspeichers"] und  [gemSpec_IDP_Frontend#Kapitel "Erzeugung des Schlüssels und weiterer Metadaten"] genügt. 

Die hier dargestellte Reihenfolge ist nicht bindend. Bedingt durch die zweimalige Leistung einer Signatur durch die eGK ist es dem Anbieter des Authenticator-Moduls überlassen, den konkreten Ablauf unter ergonomischen oder Usability-Gesichtspunkten geeignet zu gestalten und den Benutzer im Rahmen der Benutzerführung über die Wirkung der durchgeführten Aktionen aufzuklären. Der Prozess mündet (siehe 3. in der folgenden Abbildung) in die Registrierung durch die Übertragung der Pairing-Daten und des ACCESS_TOKEN an den Pairing-Endpunkt. Der Pairing-Endpunkt validiert das übertragene ACCESS_TOKEN, die übertragenen Geräteinformationen und die übertragenen Pairing-Daten. Im Erfolgsfall werden die übertragenen Pairing-Daten am Pairing-Endpunkt gespeichert.

Der Prozess wird durch das folgende Sequenzdiagramm illustriert:

Abbildung 5: Ablauf Registrierungsprozess

Hinweis: Die IDP-Dienst-interne Kommunikation zum Abruf der Pairing-Daten und der Bewertung der Gerätedaten ist in der Abbildung nicht dargestellt. Das Diagramm illustriert die Serviceaktivitäten, nicht die physische Verteilung. 

5.4.2.5.1 Erläuterungen zum Registrierungsprozess

Der Nutzer authentifiziert sich am IDP-Dienst über das Authenticator-Modul mit Hilfe der eGK oder eines bereits vorhandenen SSO_TOKEN. Das hierbei ausgestellte ACCESS_TOKEN umfasst als Claim die aus dem C.CH.AUT abgeleitete idNummer des Nutzers.

Dem Authenticator-Modul obliegt die Prüfung auf Vorliegen von geeigneten Voraussetzungen auf dem Endgerät. Die folgenden Aspekte sind hierbei eingeschlossen:

• Verfügbarkeit von geeigneten kryptographischen Algorithmen,
• Vorhandensein eines geeigneten, vom Gerät und Betriebssystem realisierten Schlüsselspeichers,
• Möglichkeit zur Erzeugung eines Schlüsselpaars,
• Möglichkeit zur Zuordnung von lokalen Authentisierungsmitteln zur Anwendung von erzeugten Schlüsseln,
• Durchsetzbarkeit von Anforderungen an die Löschung der erzeugten Schlüssel, z. B. bei Änderung von biometrischen Referenzmerkmalen oder Deinstallation des Accounts.

Das Authenticator-Modul erzeugt das Schlüsselpaar PrK_SE_AUT/PuK_SE_AUT und einen gegenüber dem IDP-Dienst verwendeten Key-Identifier. Der Nutzer signiert mithilfe des privaten Authentisierungsschlüssels PrK.CH.AUT der eGK die folgenden Daten:

• den öffentlichen Schlüssel PuK_SE_AUT und die zur Anwendung des Schlüssels zu verwendenden Algorithmen, 
• die folgenden Daten aus dem Authentifizierungszertifikat C.CH.AUT der eGK:

• den vom Hersteller vergebenen Namen des vom Nutzer verwendeten Geräts,
• ein vom Authenticator-Modul vergebener Key-Identifier des Schlüsselpaars Prk_SE_AUT/PuK_SE_AUT zur Identifikation des Schlüssels gegenüber dem IDP-Dienst.

Die Gesamtheit dieser Daten sind die Pairing-Daten.

Zum Einleiten der Registrierung werden die folgenden Daten verschlüsselt an den Pairing-Endpunkt gesandt:

• das bezogene ACCESS_TOKEN,
• die produzierten Pairing-Daten,
• das verwendete Authentisierungszertifikat C.CH.AUT der eGK,
• einen vom Benutzer vergebenen Namen für sein Gerät,
• zum Zeitpunkt der Authentisierung erhobene Geräteinformationen bestehend aus:

Die Verschlüsselung basiert auf Schlüsseln, die über das Discovery Document des IDP-Dienstes publiziert werden. Im Erfolgsfall werden der Key-Identifier, das Zertifikat C.CH.AUT und der vom Nutzer vergebene Name des Geräts lokal gespeichert.

Die Aufnahme des vom Hersteller vergebenen Namen des Geräts, dem Produktnamen, in die signierten Pairing-Daten dient dem Nutzer in Kombination mit dem von ihm vergebenen Namen des Geräts der Nachvollziehbarkeit der Zuordnung des Pairings zu einem Gerät bei einer Geräte-übergreifenden Verwaltung seiner Pairing-Daten. Es wird hierbei angenommen, dass der Produktnamen über den gesamten Lebenszyklus des Geräts hinweg konstant bleibt (insbesondere über Betriebssystem-Updates hinaus). 

Der Pairing-Endpunkt prüft:

• das ACCESS_TOKENS auf Gültigkeit,
• ob anhand der Claims des ACCESS_TOKENS die Authentifizierung auf Basis der eGK nachzuvollziehen ist,
• ob die übermittelten Geräteinformationen sich nicht auf der Block-Liste befinden,
• das übermittelte Authentifizierungszertifikats auf Gültigkeit,
• die Integrität der übermittelten Pairing-Daten mithilfe des öffentlichen Schlüssels aus dem Authentifizierungszertifikat C.CH.AUT,
• ob die im ACCESS_TOKEN vorhandene idNummer identisch mit der des übermittelten Zertifikats C.CH.AUT ist,
• ob die in den Pairing-Daten vorhandenen Angaben zu Seriennummer, Gültigkeitsende und Aussteller identisch zu denen des übermittelten Zertifikats C.CH.AUT sind und ob der in den Pairing-Daten vorhandene öffentliche Schlüssel einschließlich der Angaben zu den Algorithmen identisch zu dem in dem Zertifikat C.CH.AUT ist.

Bei Fehlschlag einer dieser Prüfungen wird der Registrierungsprozess abgebrochen. Bei Erfolg aller dieser Prüfungen werden die folgenden Daten am Pairing-Endpunkt für die weitere Verwendung im Zuge der Authentifizierung hinterlegt:

• die übertragenen Pairing-Daten einschließlich der Signaturdaten,
• den Zeitpunkt der Anlage,
• den vom Nutzer vergebenen Namen für sein Gerät,
• die idNummer und den übertragenen Key-Identifier.

Die Kombination von idNummer und Key-Identifier dient zur Referenzierung bzw. Dereferenzierung der Kombination von Pairing-Daten, Zeitpunkt der Anlage und den vom Nutzer vergebenen Namen. Das Authentifizierungszertifikat C.CH.AUT wird hierbei nicht gespeichert. Seine Speicherung obliegt dem Authenticator-Modul für die zukünftige Verwendung des mit dem Prozess etablierten alternativen Authentisierungsmittels.

5.4.2.5.2 Spezifikation

Hinweis: Festlegung zur Ausgestaltung der Datenformate und Kommunikationsprotokolle finden sich im Anhang C dieses Dokuments.
Der Authorization-Endpunkt und der Pairing-Endpunkt müssen das zusätzliche Attribut Security-Patchlevel ("security_patchlevel") in der Authentication_Data/Device_Information/Device_Type-Struktur (Version 1.1) annehmen können ohne es zur Bewertung des Gerätetyps auf Basis der Block/Allow-Liste zu nutzen. Des Weiteren müssen der Authorization-Endpunkt und der Pairing-Endpunkt auch zukünftig die vorherige Version der Authentication_Data/Device_Information/Device_Type-Struktur (Version 1.0) ohne das Attribut Security-Patchlevel ("security_patchlevel") annehmen. 

Hinweis: Festlegung zur Ausgestaltung der Datenformate und Kommunikationsprotokolle finden sich im Anhang C dieses Dokuments.

5.4.2.6 Verwendung von alternativen Authentisierungsmitteln

5.4.2.6.1 Erweiterung des Authorization-Endpunkts

Der Authorization-Endpunkt verwendet den im Zuge der Registrierung den in den Pairing-Daten hinterlegten öffentlichen Schlüssel zur Authentifizierung. Die erfolgreiche Authentifizierung ist abhängig von:

• der Gültigkeit des Authentisierungsmittels, das zur Registrierung des alternativen Authentisierungsmittels verwendet wurde
• der Integrität der Pairing-Daten und deren Bezug zum Authentisierungsmittel, welches bei der Registrierung verwendet wurde
• der Eignung des Geräts
• weiteren zeitlichen Bedingungen an die Verwendungszeit des auf dem Gerät des Nutzers erzeugten Authentifizierungsschlüssels zum Zweck der Authentifizierung in Abhängigkeit der festgestellten Eignung des Geräts
• der Prüfung der Signatur der Authentifizierungsdaten mithilfe des in den gespeicherten Pairing-Daten vorhandenen auf dem Gerät des Nutzers erzeugten Authentifizierungsschlüssels.

Bei Fehlschlag einer dieser Prüfungen gilt der Benutzer als nicht authentifiziert. Die Bewertung des Geräts erfolgt hierbei auf Basis von Informationen, die vom Authenticator-Modul erhoben werden.

Die Verwendung von alternativen Authentisierungsmitteln gestaltet sich in zwei Schritten:

1. Ein Anwendungsfrontend initiiert über das Authenticator-Modul einen Authorization-Request an den Authorization-Endpunkt des IDP-Dienstes. Der Authorization-Endpunkt produziert ein Challenge-Token und überträgt dieses an das Authenticator-Modul. Der Nutzer signiert über das Authenticator-Modul eine Datenstruktur, die die folgenden Inhalte umfasst:
   
2. • das empfangene Challenge-Token
   • das lokal gespeicherte Authentifizierungszertifikat
   • aktuelle Geräteinformationen und
   • Angaben zur vom Nutzer verwendeten Methode zur Freischaltung des Authentisierungsschlüssels.
     
3. Der Authorization-Endpunkt prüft die empfangenen Daten und authentifiziert den Nutzer im Erfolgsfall.

Der Ablauf ist in dem folgenden Sequenzdiagramm dargestellt:

Abbildung 6: Ablauf Verwendung alternativer Authentisierungsmittel

Hinweis: Die IDP-Dienst-interne Kommunikation zum Abruf der Pairing-Daten und der Bewertung der Gerätedaten ist in der Abbildung nicht dargestellt. Das Diagramm illustriert die Serviceaktivitäten, nicht die physische Verteilung.

5.4.2.6.2 Erläuterungen zur Verwendung von alternativen Authentisierungsmitteln

Um eine Authentifizierung mit alternativen Authentisierungsmitteln zu ermöglichen, wird das in [gemSpec_IDP_Dienst], unter Abschnitt 3.3 beschriebene Challenge-Response-Verfahren zur Nutzerauthentifizierung um die Möglichkeit zur Validierung von signierten Challenge-Token erweitert, die nicht auf Basis von Schlüsseln der eGK signiert wurden, sondern durch den PrK_SE_AUT eines Gerätes. Die Initiierung des Prozesses erfolgt wie in [gemSpec_IDP_Dienst] beschrieben über das Anwendungsfrontend und einen Authorization-Request an den Authorization-Endpunkt. Die Antwort des Authenticator-Moduls auf die Challenge des Authorization-Endpunkts gestaltet sich wie folgt: Das Authenticator-Modul produziert eine Datenstruktur, die die folgenden Informationen enthält:

• das vom IDP-Dienst bezogene Challenge-Token
• das lokal gespeicherte, zur Anlage des Pairings verwendete Authentifizierungszertifikat der eGK
• den lokal gespeicherten Key-Identifier des Schlüsselpaars PrK_SE_AUT/PuK_SE_AUT
• aktuell vom Authenticator-Modul erhobene Geräteinformationen und
• Informationen über die vom Nutzer verwendeten, lokalen Authentisierungsmittel.

Die Gesamtheit dieser Daten wird im Folgenden "Authentisierungsdaten" genannt. Der Nutzer signiert diese Daten mit dem PrK_SE_AUT und das Authenticator-Modul überträgt diese als Response auf die bezogene Challenge an den Authorization-Endpunkt. Die übertragenen Daten werden auf Basis von öffentlichen Schlüsseln, die über das Discovery Document des IDP-Dienstes publiziert werden, verschlüsselt. Den verschlüsselten Daten werden Angaben zur zeitlichen Gültigkeit beigefügt, die denen des bezogenen Challenge-Token entsprechen. 

Die Validierung der empfangenen Authentifizierungsdaten gestaltet sich wie folgt:

Der Authorization-Endpunkt prüft die empfangenen Authentifizierungsdaten vor Entschlüsselung auf zeitliche Gültigkeit. Er vollzieht nach Entschlüsselung die folgenden Schritte:

1. Prüfung, ob die übertragenen Geräteinformationen auf der Block-Liste hinterlegt sind. Ist dies der Fall, wird der Authentifizierungsvorgang abgebrochen. 
2. Prüfung, ob das übermittelte Authentifizierungszertifikat C.CH.AUT gültig ist. Ist dieses gesperrt oder abgelaufen, wird der Authentifizierungsvorgang abgebrochen.
3. Der gespeicherte Pairing-Eintrag wird anhand der Kombination von idNummer aus dem Authentifizierungszertifikat C.CH.AUT und dem übertragenen Key-Identifier dereferenziert. Existiert kein solcher, wird der Authentifizierungsvorgang abgebrochen. 
4. Die ursprünglich im Rahmen des Registrierungsprozesses vom Nutzer geleistete Signatur der Pairing-Daten wird vom Authorization-Endpunkt auf mathematische Integrität überprüft. Erweisen sich die hinterlegten Daten als verfälscht, wird der Authentifizierungsvorgang abgebrochen. 
5. Der in den Pairing-Daten vorhandene öffentliche Schlüssel PuK_SE_AUT wird zur Authentifizierung der übermittelten Authentifizierungsdaten angewendet, wenn
6. 1. die übermittelten Gerätedaten entweder auf ein Gerät auf der Allow-Liste verweisen oder
   2. andernfalls der Zeitpunkt der Anlage des Pairings nicht mehr als 6 Monate zurückliegt.  
7. Der Authorization-Endpunkt prüft die mathematische Integrität der übermittelten Authentifizierungsdaten mithilfe des öffentlichen Schlüssels PuK_CH_AUT aus den hinterlegten Pairing-Daten. 

Bei Fehlschlag einer Prüfung wird der Prozess abgebrochen. Bei erfolgreichem Durchlaufen aller Prüfungen gilt der Nutzer als authentifiziert. Alle weiteren Prozesse des Authorization-Endpunkts wie in [gemSpec_IDP_Dienst] unter Abschnitt 5.2 beschrieben werden durchlaufen und münden in der Produktion eines Authorization-Code und eines SSO_TOKEN. Die vom Authenticator-Modul übertragenen Informationen über die Art der vom Nutzer verwendeten lokalen Authentisierungsmethode zur Anwendung des PrK_SE_AUT werden als Claim in SSO_TOKEN und AUTHORIZATION_CODE verankert.

5.4.2.6.3 Spezifikation

Hinweis: Anforderungen an die initiale Verarbeitung der im Zuge der Authentifizierung empfangenen Datenstruktur "Authentication_Data" stellt die Anforderung A_20699-03.

Hinweis: Die Prüfung auf ein ungeeignetes Gerät durch Abfrage der Block/Allow-Liste erfolgt in Anforderung A_21432.

5.4.2.7 Inspektion und De-Registrierung der am Pairing-Endpunkt gespeicherten Daten

5.4.2.7.1 Inspektion am Pairing-Endpunkt

Die Inspektionsfunktion gestattet dem Nutzer unter Verwendung des Authenticator-Moduls die von ihm am Pairing-Endpunkt gespeicherten Daten in Augenschein zu nehmen. Bedingung für die Nutzung der Inspektionsfunktion ist die Authentisierung des Nutzers am IDP-Dienst (unter Verwendung von eGK, SSO_TOKEN oder Pairing) belegt durch die Vorlage eines gültigen ACCESS_TOKEN. Die Prüfung des ACCESS_TOKEN beinhaltet keine weiteren Anforderungen, die über die in [gemSpec_IDP_FD], Abschnitt 6 hinausgehen. Die Authentifizierung kann hierbei  auf Basis jedes vom IDP-Dienst zur Authentifizierung akzeptierten Mittels erfolgen. Das ACCESS_TOKEN enthält die ID-Nummer des Nutzers. Anhand der idNummer lassen sich alle am Pairing-Endpunkt hinterlegten Pairing-Einträge dereferenzieren. Diese werden dem Nutzer zur Ansicht übermittelt. Sie umfassen:

• die signierten Pairing-Daten,
• den Zeitpunkt der Anlage des Pairings und
• den vom Nutzer zugewiesenen Namen des Geräts.

Der Ablauf ist im folgenden Sequenzdiagramm dargestellt:

Abbildung 7: Inspektion der Pairing-Daten

5.4.2.7.2 Deregistrierung von alternativen Authentisierungsmitteln

Die Deregistrierungsfunktion gestattet dem Nutzer, von ihm gespeicherte Pairing zu deaktivieren, das heißt den öffentlichen Schlüssel dauerhaft von der Verwendung als Mittel zur Authentifizierung auszuschließen. Bedingung für die Nutzung der Deregistrierungsfunktion ist das Vorliegen eines gültigen ACCESS_TOKEN und die Darstellung der Daten analog wie in Abschnitt 5.4.2.7.1 Inspektion am Pairing-Endpunkt  beschrieben.

Der Nutzer erhält die Option zur Auswahl eines zu deaktivierenden Pairing. Das Authenticator-Modul überträgt den Key-Identifier des gewählten Pairing-Datensatzes und den bereits bezogenen ACCESS_TOKEN zum Pairing-Endpunkt. Der Pairing-Endpunkt referenziert den zu deaktivierenden Pairing-Eintrag anhand der idNummer im ACCESS_TOKEN und dem übermittelten Key-Identifier. Der Anbieter des IDP-Dienstes ist verpflichtet, den identifizierten Pairing-Eintrag binnen einer definierten Frist von der Verwendung zur Authentifizierung dauerhaft auszuschließen. Die Konkretisierung der Fristsetzung findet sich in den folgenden Anforderungen. 

Motivation: Die Realisierung der Funktion soll dem Nutzer eine umfassende Möglichkeit geben, alternative Authentisierungsmittel voraussetzungslos zu deaktivieren (z. B. in Situationen, in denen ein Verlust oder Defekt eines Gerätes eine lokale Löschung von Authentisierungsmitteln ausschließt). 

Der Ablauf ist in folgendem Sequenzdiagramm dargestellt:

Abbildung 8: Deregistrierung eines Pairings

5.4.2.7.3 Spezifikation

Hinweis: Die Ausgestaltung der Datenformate und Kommunikationsprotokolle ist im Anhang C dieses Dokuments dargelegt.

Hinweis: Die Ausgestaltung der Fehlermeldungen ist im Anhang C dieses Dokuments dargelegt.

5.5 Authentisierung über andere IDPs

Der IDP-Dienst muss in seiner Rolle als Authorization-Server des E-Rezept Fachdienstes einen Third-Party-Authorization Endpoint bereitstellen, an welchem Authorization Requests eingereicht werden, bei denen die eigentliche Authentisierung anschließend unter Nutzung eines sektoralen Identity Provider durchgeführt werden soll. Nach erfolgter Authentisierung erzeugt der IDP-Dienst aus den Daten des abgerufenen ID_TOKEN die eigenen ACCESS_TOKEN für das Anwendungsfrontend und den Fachdienst.

5.5.1 Authentifizierung über andere IDPs - Eingangsdaten

Der Request geht als Antwort in Form eines HTTP-302-redirect auf den Authorisierungs-Request zurück an das Authenticator-Modul (vergleiche Schritt 2 in). Die "target_url" des redirect ist dabei die URL des Authenticator-Moduls des sektoralen Identity Provider, welches durch den Parameter "kk_app_id" gewählt wurde.

5.5.2 Authentifizierung über andere IDPs - Ausgangsdaten

Hinweis: Aufgrund der Speicherung und Referenzierung der Sitzungsdaten durch den state-Parameter, reduziert sich die Prüfung auf Gleichheit zwischen übermittelten und gespeicherten "state" auf die Prüfung des Vorhandenseins einer unter dem übermittelten "state" gespeicherten Sitzung.

Hinweis: Aufgrund der Speicherung und Referenzierung der Sitzungsdaten durch den state-Parameter, reduziert sich die Prüfung auf Gleichheit zwischen übermittelten und gespeicherten state auf die Prüfung des Vorhandenseins einer unter dem übermittelten state gespeicherten Sitzung.

Der restliche Flow gestaltet sich wie in den Dokumenten [gemSpec_IDP_Dienst], [gemSpec_IDP_Frontend] und [gemSpec_IDP_FD] beschrieben. Dieses schließt die Produktion eines geeigneten ACCESS_TOKEN durch den IDP-Dienst mit ein.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

6.5.2 Weitere Dokumente

7 Anhang B - Beispiele der Objekte und Aufrufe

Folgendes Kapitel verdeutlicht beispielhaft den Aufbau der einzelnen Objekte und Aufrufe, welche im Rahmen der Beantragung von ACCESS_TOKEN und ID_TOKEN beim IDP-Dienst generiert und ausgetauscht werden.

Die einzelnen Aufrufe werden den Schritten aus Kapitel "3.3 Verfahrensbeschreibung" zugewiesen und in entsprechenden Unterkapiteln dargestellt.

Diese Beispiele ersetzen die vorher an verschiedenen Stellen des Dokumentes verteilten Darstellungen.

Die gematik wird weitere Beispielsätze auf ihrer Webseite in jeweils aktueller Form bereitstellen.

7.1 Authorization Request

2. Das Anwendungsfrontend überträgt seinen Authorization Request inklusive der generierten Werte  CODE_CHALLENGE, State und Nonce gemäß [RFC8252 # Anhang B] an das Authenticator-Modul.

3. Das Authenticator-Modul überträgt den Authorization Request weiter an den Authorization-Endpunkt des IDP-Dienstes.

/sign_response?

&client_id=eRezeptApp

Die Client-ID des Primärsystems wird beim Registrieren des Primärsystems beim IDP festgelegt.

&state=AcYxMQ5MZMpRh6WOBjs8

Dieser Parameter wird vom Client zufällig generiert, um CSRF zu verhindern. Indem der Server mit diesem Wert antwortet, werden Redirects legitimiert.

&redirect_uri=http%3A%2F%2Fredirect.gematik.de%2Ferezept

Die URL wird vom Primärsystem beim Registrierungsprozess im IDP hinterlegt und leitet die Antwort des Servers an diese Adresse um.

&code_challenge=SU8xsVcUypYGUi2g-mzs7rvR2lMtQ9vyj_9Hxs0WcII

Der Hashwert des Code-Verifier wird zum IDP als Code-Challenge gesendet. Teil von PKCE.

&code_challenge_method=S256

Das Primärsystem generiert einen Code-Verifier und erzeugt darüber einen Hash im Verfahren SHA-256, hier abgekürzt als S256. Teil von PKCE.

&response_type=code

Referenziert den erwarteten Response-Type des Flows. Muss immer 'code' lauten. Damit wird angezeigt, dass es sich hierbei um einen Authorization Code Flow handelt. Für eine nähere Erläuterung siehe OpenID-Spezifikation.

&nonce=nN4LkW1moAwg1tofYZtf

String zur Verhinderung von CSRF-Attacken. Dieser Wert ist optional. Wenn er mitgegeben wird, muss der gleiche Wert im abschließend ausgegebenen ID_TOKEN wiederauftauchen.

scope=openid+e-rezept

Der Scope entspricht dem zwischen E-Rezept-Fachdienst und IDP festgelegten Wert. Mit diesem antwortet der E-Rezept-Fachdienst bei fehlendem ACCESS_TOKEN und http-Statuscode 401.

&idp_iss=kk_idp_4711

Nur für Requests an den 3rd Party Authorization_Endpoint des IDP-Dienstes durch das E-Rezept-FdV. Eindeutiger interner Identifier des anzufragenden sektoralen Identity Provider, welcher für die Authentisierung des Nutzers gewählt wurde.

7.2 Authorization Response

7. Der Authorization-Endpunkt überträgt CHALLENGE und Consent-Abfrage USER_CONSENT zum Authenticator-Modul.

200

Cache-Control=no-store,

Pragma=no-cache,

Version=0.1-SNAPSHOT,

Content-Type=application/json,

Transfer-Encoding=chunked,

Date=<Zeitpunkt der Antwort. Beispiel Fri, 05 Feb 2021 12:46:20 GMT>

Keep-Alive=timeout=60,

Connection=keep-alive

Response-Body:

{

   "challenge": "eyJhbGciOiJC...",

   "user_consent": {

     "requested_scopes": {

       "e-rezept": "Zugriff auf die E-Rezept-Funktionalität.",

       "openid": "Zugriff auf den ID_TOKEN."

     },

     "requested_claims": {

       "organizationName": "Zustimmung zur Verarbeitung der Organisationszugehörigkeit",

       "professionOID": "Zustimmung zur Verarbeitung der Rolle",

       "idNummer": "Zustimmung zur Verarbeitung der ID (z.B. Krankenversichertennummer, Telematik-ID)",

       "given_name": "Zustimmung zur Verarbeitung des Vornamens",

       "family_name": "Zustimmung zur Verarbeitung des Nachnamens",

       "display_name": "Zustimmung zur Verarbeitung des Anzeigenamens"

     }

   }

}

CHALLENGE_TOKEN:

{

   "alg": "BP256R1",

   "typ": "JWT",

   "kid": "puk_idp_sig"

}

{

   "iss": "http://url.des.idp",

   "response_type": "code",

   "snc": "[server-nonce. Wird verwendet, um noise hinzuzufügen. Beispiel: \"yvqCVQO09TFsFfaJ312RfYoi1oII0BHtIDIRpzD8Gu0\"]",

   "code_challenge_method": "S256",

   "token_type": "challenge",

   "nonce": "nN4LkW1moAwg1tofYZtf",

   "client_id": "eRezeptApp",

   "scope": "openid e-rezept",

   "state": "AcYxMQ5MZMpRh6WOBjs8",

   "redirect_uri": "http://redirect.gematik.de/erezept",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244172]",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243992]",

   "code_challenge": "SU8xsVcUypYGUi2g-mzs7rvR2lMtQ9vyj_9Hxs0WcII",

   "jti": "[A unique identifier for the token, which can be used to prevent reuse of the token. Value is a case-sensitive string. Beispiel: \"07925bdc7c5d9990\"]"

}

7.3 Authentication Request

10. Das Authenticator-Modul überträgt signierte CHALLENGE mit dem Smartcard-Zertifikat an den IDP-Dienst (Antwort Schritt 7).

https://<FQDN Server>/<AUTHORIZATION_ENDPOINT>

Multiparts:

signed_challenge=<signierter und anschließend verschlüsselter Challenge Token>

Challenge Response (Encryption Header):

{

   "alg": "ECDH-ES",

   "enc": "A256GCM",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244172]",

   "cty": "NJWT",

   "epk": {

     "kty": "EC",

     "x": "LgkJSQwrz1bCoFjSLhay9O7TLaQImYW7jeOF6XmpQX4",

     "y": "dTC6ri-f1QqpJp7M4LLg0lw4FzrzNc29nrrzjPwEWWc",

     "crv": "BP-256"

   }

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Die verschlüsselte Challenge Response."

} 

Challenge Response (Decrypted):

{

   "typ": "JWT",

   "cty": "NJWT",

   "alg": "BP256R1",

   "x5c": [

     "[Enthält das verwendete Signer-Zertifikat als Base64 ASN.1 DER-Encoding. Hier kommt ausnahmsweise NICHT URL-safes Base64-Encoding zum Einsatz!]"

   ]

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Dieses Token ist die vom Server in der vorigen Nachricht übergebene Challenge. Sie muss exakt wie empfangen auch wieder übertragen werden. "

}

7.3.1 Authentication Request (SSO)

10. Falls ein SSO_TOKEN beim Authenticator-Modul existiert, wird dieser Token zusammen mit einem unveränderten CHALLENGE_TOKEN zum IDP-Dienst transportiert.

https://<FQDN Server>/<SSO_ENDPOINT> 

Multiparts:

sso_token=<SSO-Token des IDP>

unsigned_challenge = < unveränderter Challenge_Token>

7.4 Authentication Response

14. Der Authorization-Endpunkt überträgt den AUTHORIZATION_CODE und den SSO_TOKEN an das Authenticator-Modul (Antwort Schritt 3).

302

Cache-Control=no-store,

Pragma=no-cache,

Location=http://redirect.gematik.de/erezept?

code=<Authorization Code in Base64-URL-Safe Encoding. Wird unten detaillierter aufgeführt> Der Authorization-Code. Er berechtigt zur Abholung eines ACCESS_TOKEN. Er ist vom IDP für den IDP verschlüsselt und dementsprechend vom Client nicht weiter zu verarbeiten.

&state=AcYxMQ5MZMpRh6WOBjs8 Der state der Session. Sollte dem zufällig generierten state-Wert aus der initialen Anfrage entsprechen.

&ssotoken=<SSO-Token in Base64-URL-Safe Encoding. Wird unten detaillierter aufgeführt> Der SSO-Token. Mit diesem kann der Client sich wiederholt einloggen, ohne erneut den Besitz der Karte durch Unterschreiben einer Challenge beweisen zu müssen. Er ist vom IDP für den IDP verschlüsselt und dementsprechend vom Client nicht weiter zu verarbeiten. - Nicht im Fall der Anmeldung über ein Primärsystem.   

Content-Length=0,

Date=<Zeitpunkt der Antwort. Beispiel Fri, 05 Feb 2021 12:46:20 GMT>

Keep-Alive=timeout=60, Connection=keep-alive 

Response-Body:

Die Inhalte von Authorization Code und SSO_TOKEN sind IDP-spezifisch und nicht normativ vorgegeben. Sie dienen hier nur dem Verständnis.   

Authorization Code (Encryption Header):

{   "alg": "dir",

   "enc": "A256GCM",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244053]",

   "cty": "NJWT"

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Der Authorization Code"

}   

Authorization Code (Decrypted):

{

   "alg": "BP256R1",

   "typ": "JWT",

   "kid": "puk_idp_sig"

}

{

   "organizationName": "AOK Plus",

   "professionOID": "1.2.276.0.76.4.49",

   "idNummer": "X114428530",

   "iss": "http://url.des.idp",

   "response_type": "code",

   "snc": "[server-nonce. Wird verwendet, um noise hinzuzufügen. Beispiel: \"Ay6WUqtAUcV2p9WZYHPo\"]",

   "code_challenge_method": "S256",

   "given_name": "Juna",

   "display_name": "Juna Fuchs",

   "token_type": "code",

   "nonce": "nN4LkW1moAwg1tofYZtf",

   "client_id": "eRezeptApp",

   "scope": "openid e-rezept",

   "auth_time": "[Timestamp der Authentisierung. Beispiel: 1618243993]",

   "redirect_uri": "http://redirect.gematik.de/erezept",

   "state": "AcYxMQ5MZMpRh6WOBjs8",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244053]",

   "family_name": "Fuchs",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243993]",

   "code_challenge": "SU8xsVcUypYGUi2g-mzs7rvR2lMtQ9vyj_9Hxs0WcII",

   "jti": "[A unique identifier for the token, which can be used to prevent reuse of the token. Value is a case-sensitive string. Beispiel: \"6e8a61e316472f3b\"]"

}     

SSO Token (Encryption Header):

{

   "alg": "dir",

   "enc": "A256GCM",

   "exp": "[Gültigkeit des Token. Beispiel: 1618287193]",

   "cty": "NJWT"

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Das SSO Token"

}   

SSO Token (Decrypted):

{

   "alg": "BP256R1",

   "typ": "JWT",

   "kid": "puk_idp_sig"

}

{

   "organizationName": "AOK Plus",

   "professionOID": "1.2.276.0.76.4.49",

   "auth_time": "[Timestamp der Authentisierung. Beispiel: 1618243993]",

   "idNummer": "X114428530",

   "iss": "http://url.des.idp",

   "cnf": {

     "x5c": [

       "[Enthält das verwendete Signer-Zertifikat als Base64 ASN.1 DER-Encoding. Hier kommt ausnahmsweise NICHT URL-safes Base64-Encoding zum Einsatz!]"

     ],

     "kid": "844508318621525",

     "kty": "EC",

     "crv": "BP-256",

     "x": "dTXa6yPKCjIr9MbVFxeaLEu82xSCsRrfwcIrLpFqBCs",

     "y": "AJGsJ1cCyGEpCH0ss8JvD4OAHJS8IMm1_rM59jliS-1O"   },

   "given_name": "Juna",

   "display_name": "Juna Fuchs",

   "exp": "[Gültigkeit des Token. Beispiel: 1618287193]",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243993]",

   "family_name": "Fuchs"

}

7.4.1 Authentication Response (SSO Flow)

Falls das Authenticator-Modul ein vorhandenes SSO_TOKEN an den Authorization-Endpunkt zur Erlangung eines AUTHORIZATION_CODE geschickt hat, wird kein neues SSO_TOKEN vom Authorization -Endpunkt erstellt und verschickt.

302

Cache-Control=no-store,

Pragma=no-cache,

Location=https://<FQDN Server>/<TOKEN_ENDPOINT>

     ?code=<Authorization Code des IDP>

     &state=<OAuth 2.0 state value. Constant over complete flow. Value is a case-sensitive string. Beispiel: 'mlE7xX1ysbZQ4Of5YiZ8'>,

Content-Length=0,

Date=<Zeitpunkt der Antwort. Beispiel Fri, 05 Feb 2021 12:46:20 GMT>

Keep-Alive=timeout=60,

Connection=keep-alive

7.5 Token Request

16. Das Anwendungsfrontend sendet CODE_VERFIER und AUTHORIZATION_CODE zum Token-Endpunkt des IDP-Dienstes.

https://<FQDN Server>/<TOKEN_ENDPOINT>

Multiparts:

client_id=eRezeptApp

&code=<Authorization Code des IDP>

&grant_type=authorization_code

&key_verifier=<verschlüsselter KEY_VERIFIER>

&redirect_uri=http%3A%2F%2Fredirect.gematik.de%2Ferezept

Key_verifier (Encryption Header):

{

   "alg": "ECDH-ES",

   "enc": "A256GCM",

   "cty": "JSON",

   "epk": {

     "kty": "EC",

     "x": "jqrGQlZqCGQgK7OtJj0gfWPWSbStracf_PreBrA05Lc",

     "y": "V4bbOGUgr-AV6NFLnPJNYkyPLcR_1QkGlR6w4bK1wdI",

     "crv": "BP-256"   } } 

Key_verifier (Body)

  {

   "token_key": "T0hHOHNKOTFaREcxTmN0dVRKSURraTZxNEpheGxaUEs",

   "code_verifier": "W91A37hQ8oeDRVpnkYgpYthjl4LqYy95A87ISy9zpUM"

}

7.6 Token Response

20. Der Token-Endpunkt überträgt die Token an das Anwendungsfrontend (Antwort Schritt 16).

200

Cache-Control=no-store,

Pragma=no-cache,

Version=0.1-SNAPSHOT,

Content-Type=application/json,

Transfer-Encoding=chunked,

Date=<Zeitpunkt der Antwort. Beispiel Fri, 05 Feb 2021 12:46:20 GMT>

Keep-Alive=timeout=60,

Connection=keep-alive

Response-Body:

{

   "expires_in": 300,

   "token_type": "Bearer",

   "id_token": <Mit dem Token_Key verschlüsseltes ID_TOKEN.>

  "access_token": <Mit dem Token_Key verschlüsseltes ACCESS_TOKEN.>}

Access Token (Encryption Header):

{   "alg": "dir",

   "enc": "A256GCM",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244294]",

   "cty": "NJWT"

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Das ACCESS_TOKEN"

} 

Access Token (Decrypted):

{

   "alg": "BP256R1",

   "typ": "at+JWT",

   "kid": "puk_idp_sig"

}

{

   "sub": "[subject. Base64(sha256(audClaim + idNummerClaim + serverSubjectSalt)). Beispiel: \"ez4D403gBzH1IhnYOXA4aUU-7spqPbWUyUELPoA79CM\"]",

   "professionOID": "1.2.276.0.76.4.49",

   "organizationName": "AOK Plus",

   "idNummer": "X114428530",

   "amr": [

     "mfa",

     "sc",

     "pin"   ],

   "iss": "http://url.des.idp",

   "given_name": "Juna",

   "display_name": "Juna Fuchs",

   "client_id": "eRezeptApp",

   "acr": "gematik-ehealth-loa-high",

   "aud": "https://erp-test.zentral.erp.splitdns.ti-dienste.de/",

   "azp": "eRezeptApp",

   "scope": "openid e-rezept",

   "auth_time": "[Timestamp der Authentisierung. Beispiel: 1618243993]",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244294]",

   "family_name": "Fuchs",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243994]",

   "jti": "[A unique identifier for the token, which can be used to prevent reuse of the token. Value is a case-sensitive string. Beispiel: \"c0bf3cebe428e3c9\"]"

}

ID Token (Encryption Header):

{

   "alg": "dir",

   "enc": "A256GCM",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244294]",

   "cty": "NJWT"

}

{

   "njwt": "[Ein verschachtelt enthaltenes JWT] - Das ID Token"

}

ID Token (Decrypted):

{

   "alg": "BP256R1",

   "typ": "JWT",

   "kid": "puk_idp_sig"

}

{

   "at_hash": "[Erste 16 Bytes des Hash des Authentication Token Base64(subarray(Sha256(authentication_token), 0, 16)). Beispiel: \"5AZmDxrYImUa6-kjMNAL3g\"]",

   "sub": "[subject. Base64(sha256(audClaim + idNummerClaim + serverSubjectSalt)). Beispiel: \"ez4D403gBzH1IhnYOXA4aUU-7spqPbWUyUELPoA79CM\"]",

   "organizationName": "AOK Plus",

   "professionOID": "1.2.276.0.76.4.49",

   "idNummer": "X114428530",

   "amr": [

     "mfa",

     "sc",

     "pin"   ],

   "iss": "http://url.des.idp",

   "given_name": "Juna",

   "display_name": "Juna Fuchs",

   "nonce": "nN4LkW1moAwg1tofYZtf",

   "aud": "eRezeptApp",

   "acr": "gematik-ehealth-loa-high",

   "azp": "eRezeptApp",

   "auth_time": "[Timestamp der Authentisierung. Beispiel: 1618243993]",

   "scope": "openid e-rezept",

   "exp": "[Gültigkeit des Token. Beispiel: 1618244294]",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243994]",

   "family_name": "Fuchs",

   "jti": "[A unique identifier for the token, which can be used to prevent reuse of the token. Value is a case-sensitive string. Beispiel: \"c1c760ca67fe1306\"]"

}

7.7 Aufbau des Discovery Document

{

   "alg": "BP256R1",

   "kid": "puk_disc_sig",

   "x5c": [

     "[Enthält das verwendete Signer-Zertifikat als Base64 ASN.1 DER-Encoding. Hier kommt ausnahmsweise NICHT URL-safes Base64-Encoding zum Einsatz!]"

   ]

}

{

   "authorization_endpoint": "[URL des Authorization Endpunkts.]",

   "federation_authorization_endpoint": "[URL des Authorization Endpunkt für Anfragen an IDPs der Föderation - dieser ist nur im Internet verfügbar

]",

   "auth_pair_endpoint": "[URL des Pairing-Authorization-Endpunkts - dieser ist nur im Internet verfügbar]"      

   "third_party_authorization_endpoint" : "[URL des third_party-Authorization-Endpunkts - dieser ist nur im Internet verfügbar]"  

   "sso_endpoint": "[URL des SSO-Authorization Endpunkts.]",

   "uri_pair": "[URL des Pairing-Endpunkts.]",

   "token_endpoint": "[URL des Authorization-Endpunkts.]",

   "uri_disc": "[URL des Discovery Document.]",

   "issuer": "http://url.des.idp",

   "jwks_uri": "[URL einer JWKS-Struktur mit allen vom Server verwendeten Schlüsseln]",

   "exp": "[Gültigkeit des Token. Beispiel: 1618330390]",

   "iat": "[Zeitpunkt der Ausstellung des Token. Beispiel: 1618243990]",

   "uri_puk_idp_enc": "http://url.des.idp/idpEnc/jwk.json",

   "uri_puk_idp_sig": "http://url.des.idp/idpSig/jwk.json",

   "subject_types_supported": [

     "pairwise"

   ],

   "id_token_signing_alg_values_supported": [

     "BP256R1"

   ],

   "response_types_supported": [

     "code"

   ],

   "scopes_supported": [

     "openid",

     "e-rezept"

     "pairing"

   ],

   "response_modes_supported": [

     "query"

   ], 

 "grant_types_supported": [

     "authorization_code"

   ],

   "acr_values_supported": [

     "gematik-ehealth-loa-high"

   ],

   "token_endpoint_auth_methods_supported": [

     "none"

   ],

   "code_challenge_methods_supported": [

     "S256"

   ]

}

8 Anhang C - Datenformate und Kommunikationsprotokolle im Zusammenhang mit alternativen Authentisierungsverfahren

8.1 Datentypen

Die Verwendung der hier genannten Datentypen und ihre Ausgestaltung sind verpflichtend. Gleiches gilt für die dargestellte Detaillierung der Kommunikationsprotokolle. 

8.1.1 Übergeordnete Anforderungen

Die folgenden Festlegungen gelten übergeordnet für alle verwendeten Datentypen.

8.1.1.1 Kodierung

Tabelle 12: Kodierung von Daten

8.1.1.2 Versionierung

Die in den folgenden Abschnitten genannten Datentypen enthalten eine Name-/Wert-Kombination zur Anzeige der Version der Datenobjekte. Diese ist "<Name des Datenobjektes>_version". Der Wert ist konstant mit "1.0" zu belegen.

8.1.1.3 Namen und Claims

Namen von JSON-Elementen sind ausnahmslos in sog. "Snake-Case" dargestellt. Namen von Datenobjekten in Großschreibung.

8.1.2 Datentyp "Device_Type"

Der Datentyp "Device_Type" wird zur Übertragung von Informationen über einen Gerätetyp vom Authenticator-Modul zum IDP-Dienst verwendet. Der Datensatz wird vom Authenticator-Modul produziert und vom Pairing-Endpunkt und dem Authorization-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas:

Tabelle 13: Schema Datentyp "Device_Type"

8.1.3 Datentyp "Device_Information"

Der Datentyp "Device_Information" wird zur Übertragung von Informationen über ein Gerät verwendet. Der Datensatz wird vom Authenticator-Modul produziert und vom Pairing-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 14: Schema Datentyp "Device_Information"

8.1.4 Datentyp "Pairing_Data"

Der Datentyp "Pairing_Data" wird zur Bindung des PuK_SE_AUT an Metadaten verwendet. Der Datentyp wird vom Authenticator-Modul produziert und von Pairing-Endpunkt und Authorization-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 15: Schema Datentyp "Pairing_Data"

8.1.5 Datentyp "Signed_Pairing_Data"

Der Datentyp "Signed_Pairing_Data" repräsentiert den vom Nutzer mithilfe der eGK signierte Instanz des Datentyps "Pairing_Data". Der Datentyp wird vom Authenticator-Modul produziert und von Pairing-Endpunkt und Authorization-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 16: Schema Datentyp "Signed_Pairing_Data"

8.1.6 Datentyp "Registration_Data"

Der Datentyp "Registration_Data" bündelt die zur Verifikation und Anlage eines Pairing benötigten Daten. Der Datentyp wird vom Authenticator-Modul produziert und vom Pairing-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 17: Schema Datentyp "Registration_Data"

8.1.7 Datentyp "Encrypted_Registration_Data"

Der Datentyp "Encrypted_Registration_Data" repräsentiert die verschlüsselte Form einer "Registration_Data"-Instanz. Der Datentyp wird vom Authenticator-Modul produziert und vom Pairing-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 18: Schema Datentyp "Encrypted_Registration_Data"

8.1.8 Datentyp "Authentication_Data"

Der Datentyp "Authentication_Data" repräsentiert die zur Authentifizierung des Nutzers verwendeten Daten. Der Datentyp wird vom Authenticator-Modul produziert und vom Authorization-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 19: Schema Datentyp "Authentication_Data"

8.1.9 Datentyp "Signed_Authentication_Data"

Der Datentyp "Signed_Authentication_Data" repräsentiert die vom Nutzer mithilfe des PrK_SE_AUT signierte Instanz einer "Authentication_Data"-Struktur. Der Datentyp wird vom Authenticator-Modul produziert und vom Authorization-Endpunkt verwendet.  Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 20: Schema Datentyp "Signed_Authentication_Data"

8.1.10 Datentyp "Encrypted_Signed_Authentication_Data"

Der Datentyp "Encrypted_Signed_Authentication_Data" repräsentiert eine verschlüsselte "Signed_Authentication_Data"-Instanz. Der Datentyp wird vom Authenticator-Modul produziert und vom Authorization-Endpunkt verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 21: Schema Datentyp "Encrypted_Signed_Authentication_Data"

8.1.11 Datentyp "Pairing_Entry"

Der Datentyp "Pairing_Entry" repräsentiert die am Pairing-Endpunkt gespeicherten Daten. Der Datentyp wird vom Pairing-Endpunkt produziert und vom Authenticator-Modul verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas: 

Tabelle 22: Schema Datentyp "Pairing_Entry"

8.1.12 Datentyp "Pairing_Entries"

Der Datentyp "Pairing_Entries" repräsentiert eine Liste von "Pairing_Entry"-Instanzen. Der Datentyp wird vom Pairing-Endpunkt produziert und vom Authenticator-Modul verwendet. Der Datentyp umfasst die Elemente des folgenden Schemas:

Tabelle 23: Schema Datentyp "Pairing_Entries"

8.2 Ausgestaltung der Kommunikation mit dem IDP-Dienst

8.2.1 Registrierung von alternativen Authentisierungsmitteln

8.2.1.1 Request des Authenticator-Moduls bei Registrierung

Tabelle 24: Registrierungsprozess/Anfrage Authenticator-Modul

8.2.1.2 Response des Pairing-Endpunkts bei Registrierung

Tabelle 25: Registrierungsprozess/Antwort Pairing-Endpunkt

8.2.2 Verwendung von alternativen Authentisierungsmitteln

8.2.2.1 Request des Authenticator-Moduls bei Verwendung von alternativen Authentisierungsmitteln

Tabelle 26: Authentifizierung/Anfrage Authenticator-Modul

8.2.2.2 Response des Authorization-Endpunkts bei Verwendung von alternativen Authentisierungsmitteln

Tabelle 27: Authentifizierung/Antwort Authorization-Endpunkt

8.2.3 Inspektion von Pairing-Daten am Pairing-Endpunkt

8.2.3.1 Request des Authenticator-Moduls zur Inspektion

Tabelle 28: Inspektion/Anfrage Authenticator-Modul

8.2.3.2 Response des Pairing-Endpunkts bei Inspektion

Tabelle 29: Inspektion/Antwort Pairing-Endpunkt

8.2.4 Deregistrierung von Pairing-Daten am Pairing-Endpunkt

8.2.4.1 Request des Authenticator-Moduls zur Deregistrierung

Tabelle 30: Deregistrierung/Anfrage Authenticator-Modul

8.2.4.2 Response des Pairing-Endpunkts bei Deregistrierung

Tabelle 31: Deregistrierung/Antwort Pairing-Endpunkt

8.3 Vergleichsoperationen

Die folgenden Vergleichsoperationen sind innerhalb des Ablaufs notwendig:

8.3.1 Registrierung

Tabelle 32: Vergleichsoperationen im Rahmen der Registrierung