C_11897_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

• Aktualisierung HSM-Anforderung
• SSO auch für Authentisierungen mit Biometrie ermöglichen
• Einwilligungen für starke biometrische Sensoren konkretisiert
• Generalisierung der Anforderung zum Schutz vor Replay-Attacken
• Änderung von Prüfzuordnungen, deren Anforderungen produkt- statt anbieterspezifisch sind
• Abweichende Regelungen Gastanmeldung (eGK+PIN)
• Korrektur von scope und claims
• Ergänzung epk
• Konkretisierung der Signalisierung angeforderter und verwendeter amr und acr
• Konkretisierung der Signalisierung der Einwilligung
  
• Korrektur OpenID Federation Metadaten
• Korrektur dokumenteninterner Verweise und aktualisierter externer Spezifikationen (OpenID Connect Federation)
• Korrektur redaktioneller Fehler
• Korrektur Mediatype signed_jwks_uri
• Korrektur x5c Attribut Typ

2 Änderungen in gemSpec_IDP_Sek

Änderungen in Kapitel 3.2.2 "Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld"

Alt:

Neu:

Änderungen in Kapitel 4.2.4.2 "Token-Endpunkt Ausgangsdaten"

Alt:

Neu:

Alt:

A_22989-01 - "scopes" und "claims" des sektoralen IDP für Versicherte
Ein sektoraler IDP, welcher die Identitäten für Versicherte verwaltet, MUSS mindestens die folgenden scopes und claims unterstützen:

Tabelle 5: scopes und claims

<=

Neu:

A_22989-02 - "scope" und "claims" Werte des sektoralen IDP für Versicherte
Ein sektoraler IDP, welcher die Identitäten für Versicherte verwaltet, MUSS mindestens die folgenden scopes und claims Werte unterstützen:

Tabelle 5: scopes und claims

<=

Alt:

Neu:

Änderungen in Kapitel 4.3.2 "Authentifizierungsverfahren"

Alt:

Neu:

Hinweis: ein Beispiel für den Aufbau der amr Präferenz ist der Tabelle "Parameter Pushed Authorization Request" in der Zeile "Claims" zu entnehmen

Alt:

A_23129-03 Identifikation des Authentifizierungsverfahren
Der sektorale Identity Provider MUSS den claim amr im ID_TOKEN entsprechend dem durchgeführten Authentisierungsverfahren nach folgender Tabelle belegen.

Tabelle 6: Codierung der Authentisierungsverfahren

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)

Hinweis: Das amr Claim wird generell von sektoralen IDPs im ID_TOKEN gemäß der Anforderung A_23129-03 mitgeliefert. Um ein bestimmtes Authentisierungsmittel bei der Nutzerauthentifizierung durch den sektoralen IDP zu erzwingen, fordert die Relying Party dies im Authorization Request mittels Claims Parameter an.
Beispiel: Claims Parameter (URL encoded) zum Anfordern der Nutzerauthentifizierung mit eGKclaims%3D%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22values%22%3A%5B%22urn%3Atelematik%3Aauth%3AeGK%22%5D%7D%7D%7D

Neu:

A_23129-04 Identifikation des Authentifizierungsverfahren
Der sektorale IDP MUSS den claim amr im ID_TOKEN entsprechend dem durchgeführten Authentisierungsverfahren nach folgender Tabelle belegenbefüllen.

Tabelle 6: Codierung der Authentisierungsverfahren

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)Produktgutachten

Hinweis: Das Claim amr wird generell von sektoralen IDP im ID_TOKEN gemäß der Anforderung A_23129-03* mitgeliefert. Bei dem Claim handelt es sich gemäß [OpenID Connect Core 1.0#IDToken] um ein JSON Array.

Hinweis 2: Um ein bestimmtes Authentisierungsmittel bei der Nutzerauthentifizierung durch den sektoralen IDP zu erzwingen, fordert die Relying Party dies im Authorization Request mittels Claims Parameter an. Ein Beispiel kann der Tabelle  "Parameter Pushed Authorization Request" in der Zeile zu Claims entnommen werden.
Beispiel: Claims Parameter (URL encoded) zum Anfordern der Nutzerauthentifizierung mit eGKclaims%3D%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22values%22%3A%5B%22urn%3Atelematik%3Aauth%3AeGK%22%5D%7D%7D%7D

Alt:

Neu:

Alt:

Neu:

Änderungen in Kapitel 4.3.2.1 "Gerätenutzung"

Alt:

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

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

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

angelegt werden.

Tabelle 7: Übersicht Gerätebindung

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)

Geänderte Zuordnung:

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

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

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

angelegt werden.

Tabelle 7: Übersicht Gerätebindung

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)Produktgutachten

Alt:

A_25138-01 - Erneuerung der Gerätebindung für "gematik-ehealth-loa-high"
Nach Ablauf der Gültigkeitsdauer einer Gerätebindung DARF die bestehende Gerätebindung NICHT als Authentisierungsfaktor für die Erneuerung der Gerätebindung für gematik-ehealth-loa-high verwendet werden.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

A_25138-01 - Erneuerung der Gerätebindung für "gematik-ehealth-loa-high"
Nach Ablauf der Gültigkeitsdauer einer Gerätebindung DARF die bestehende Gerätebindung NICHT als Authentisierungsfaktor für die Erneuerung der Gerätebindung für gematik-ehealth-loa-high verwendet werden.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Alt:

A_25969 - Keine Nutzung einer Gerätebindung zur Einrichtung einer Gerätebindung
Eine Gerätebindung DARF NICHT mittels einer bestehenden Gerätebindung neu eingerichtet werden.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

A_25969 - Keine Nutzung einer Gerätebindung zur Einrichtung einer Gerätebindung
Eine Gerätebindung DARF NICHT mittels einer bestehenden Gerätebindung neu eingerichtet werden.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Änderungen in Kapitel 4.3.2.2 "Nutzung von Biometrie"

Alt:

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

Tabelle 8: Biometrie

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)

Neu:

Hinweis: Durch einen redaktionellen Fehler wurde ein anderer Text der [A_23701] veröffentlicht, als in der Kommentierung freigegeben. Mit [A_23701-01] wird der ursprünglich freigegebene Inhalt wiederhergestellt.

A_23701-01 - Verwendung von Biometrie als Faktor zur Nutzerauthentifizierung
Der Anbieter desr sektoralen TIDP MUSS die in der Tabelle "Biometrie" aufgeführten Einschränkungenfür die Nutzung von biometrischenr Sensoren zur ANutzerauthentifizierung des Nutzers die in der Tabelle "Biometrie" aufgeführten Einschränkungen berücksichtigen. Für die Nutzung eines biometrischen Faktors MUSS, wenn damit eine Herabstufung des Vertrauensniveaus verbunden ist, die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial beim Zugriff auf Daten mit hohem Schutzbedarf (A_23103) vorliegen.

Tabelle 8: Biometrie

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)Produktgutachten

Am Ende des Kapitels wird hinzugefügt

Neu:

A_26591 - Einwilligung zur Verwendung biometrischer Sensoren
Der sektorale IDP MUSS die explizite Einwilligung zur Verwendung der in Tabelle "Biometrie" zugelassenen biometrischen Sensoren einholen, wenn diese Sensoren nicht die erforderliche Güte für die uneingeschränkte Nutzung auf dem Vertrauensniveau gematik-ehealth-loa-substantial beziehungsweise gematik-ehealth-loa-high erfüllen. Dabei MUSS der sektorale IDP sicherstellen, dass der Nutzer über die damit verbundenen Risiken hinreichend informiert wurde, die Einwilligung des Nutzers vollständig freiwillig erfolgt und die Einwilligung kryptografisch abgesichert ist.
Diese Einwilligung MUSS durch den sektoralen IDP für jedes zu verwendende Endgerät eingeholt werden, unabhängig von bereits erfolgten Einwilligungen auf anderen Endgeräten. Der sektorale IDP MUSS sicherstellen, dass erteilte Einwilligungen auf den jeweiligen Geräten durch den Nutzer widerrufen werden können.

<=, IDP-Sek, Sich.techn. Eignung: Produktgutachten

Änderungen in Kapitel 4.3.2.3 "Unterstützung Single-Sign-On (SSO) auf Anwendungsebene"

Alt:

A_23207-01 - Single Sign-On (SSO) als Authentifizierungsverfahren
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS im Claim acr das Niveau beauskunften, welches dem der vorhergehenden Authentisierung entspricht. Der Claim amr MUSS auf den Wert urn:telematik:auth:sso gemäß der Tabelle "Codierung der Authentisierungsverfahren" gesetzt werden.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Neu:

A_23207-02 - Single Sign-On (SSO) als Authentifizierungsverfahren
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS im claim acr das Niveau beauskunften, welches dem der vorhergehenden Authentisierung entspricht. Der claim amr MUSS aufum den Wert urn:telematik:auth:sso gemäß der Tabelle "Codierung der Authentisierungsverfahren" gesetzterweitert werden.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Alt:

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

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)

Geänderte Zuordnung:

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

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)Produktgutachten

Alt:

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

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Neu:

A_24721-02 Ausstellen einer SessionID zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO im Ablauf der ersten erfolgreichen Nutzerauthentisierung eine SessionID zum laufenden Nutzerkontext generieren und diese an das Authenticator-Modul des Anwendungskontextes übertragen. Der Hersteller MUSS sicherstellen, dass eine ausgestellte SessionID nur nach erfolgreicher Authentisierung und ausschließlich für den jeweiligen Nutzerkontext verwendet werden kann und spätestens nach der in A_23212 festgelegten Zeitspanne nach der letzten Nutzerinteraktion am Authenticator-Modul oder durch explizite Signalisierung der Beendigung des Anwendungskontextes durch die Anwendung gelöscht wird.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Hinweis: Unter Nutzerkontext sind die Informationen zu einem Nutzer zu verstehen, die mit der SessionID nach erfolgreicher Nutzerauthentifizierung mittels Authenticator durch den IDP assoziiert sind. Deshalb spricht man auch von einer Subject-Session, die durch die SessionID identifiziert ist. Der Anwendungskontext hingegen erstreckt sich über die Anwendung, also alle Komponenten und Dienste, die funktional für diese Anwendung benötigt werden.

Alt:

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

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

Ist die Prüfung nicht erfolgreich, so MUSS der sektorale IDP eine Nutzerauthentisierung mit Nutzerinteraktion durchführen.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

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

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

Ist die Prüfung nicht erfolgreich, so MUSS der sektorale IDP eine Nutzerauthentisierung mit Nutzerinteraktion durchführen.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Alt:

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

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

In diesen Fällen ist eine erneute Nutzerauthentisierung mit aktiver Nutzerinteraktion notwendig.

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)

Geänderte Zuordnung:

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

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

In diesen Fällen ist eine erneute Nutzerauthentisierung mit aktiver Nutzerinteraktion notwendig.

<=, Anb_IDP-Sek_KTR, Sich.techn. Eignung: Gutachten (Anbieter)Produktgutachten

Änderungen in Kapitel 5.2.2 "Rahmenbedingungen"

Alt:

Die Anforderungen in diesem Kapitel und die zusätzlichen Informationen im Kapitel 7.4 betreffen nur Hersteller, die ein SSO auf Anwendungsebene implementieren. Für Hersteller, die kein SSO auf Anwendungsebene umsetzen, gelten die Anforderungen dieses Kapitels nicht.

Neu:

Die Anforderungen in diesem Kapitel und die zusätzlichen Informationen im Kapitel 7.4"Unterstützung Single-Sign-On auf Anwendungsebene" betreffen nur Hersteller, die ein SSO auf Anwendungsebene implementieren. Für Hersteller, die kein SSO auf Anwendungsebene umsetzen, gelten die Anforderungen dieses Kapitels nicht.

Alt:

A_24722-01 - Ausstellen eines Schlüssels zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO nach der ersten erfolgreichen Nutzerauthentisierung im Schlüsselspeicher des Nutzergerätes ein Schlüsselpaar generieren und an den laufenden Anwendungskontext sowie an die vom sektoralen IDP erhaltenen SessionID binden. Das Authenticator-Modul MUSS nach der ersten erfolgreichen Nutzerauthentisierung den öffentlichen Schlüssel und die mit dem privaten Schlüssel signierte SessionID zum Anwendungskontext an den sektoralen IDP übertragen. Der Hersteller von sektoralen IDP MUSS sicherstellen, dass das zu einem Anwendungskontext generierte Schlüsselpaar und SessionID nach dem Schließen des Anwendungskontextes aus dem Schlüsselspeicher des Geräts gelöscht werden.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

A_24722-01 - Ausstellen eines Schlüssels zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO nach der ersten erfolgreichen Nutzerauthentisierung im Schlüsselspeicher des Nutzergerätes ein Schlüsselpaar generieren und an den laufenden Anwendungskontext sowie an die vom sektoralen IDP erhaltenen SessionID binden. Das Authenticator-Modul MUSS nach der ersten erfolgreichen Nutzerauthentisierung den öffentlichen Schlüssel und die mit dem privaten Schlüssel signierte SessionID zum Anwendungskontext an den sektoralen IDP übertragen. Der Hersteller von sektoralen IDP MUSS sicherstellen, dass das zu einem Anwendungskontext generierte Schlüsselpaar und SessionID nach dem Schließen des Anwendungskontextes aus dem Schlüsselspeicher des Geräts gelöscht werden.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Alt:

A_24768-01 Wechsel des Schlüssels zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO das im Authenticator-Modul zum laufenden Anwendungskontext generierte Schlüsselpaar nach spätestens 3 Minuten erneuern.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Neu:

A_24768-02 - Schutz vor Replay-Attacken innerhalb eines Anwendungskontextes
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS ein geeignetes Verfahren zum Schutz vor Replay-Attacken implementieren.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Hinweis 1: Ein solches Verfahren kann beispielsweise durch eine Erneuerung des im Authenticator-Modul zum laufenden Anwendungskontext generierten Schlüsselpaares nach spätestens 3 Minuten und eine geschützte Übertragung des öffentlichen Schlüssels zum IDP umgesetzt werden.

Hinweis 2: Die beispielhaften Ablaufsequenzen (Key-Rotation und Server-Nonce) sind informativ im Anhang dargestellt.

Alt:

A_24723-01 - Signieren der SessionID zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO bei jeder Nutzerauthentisierung ohne Nutzerinteraktion im Authenticator-Modul die vom sektoralen IDP übertragene SessionID zur laufenden Anwendungsinstanz mit dem zur SessionID auf dem Gerät des Versicherten gespeicherten Schlüssel signieren und an den sektoralen IDP übertragen.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

A_24723-01 - Signieren der SessionID zu einem Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO bei jeder Nutzerauthentisierung ohne Nutzerinteraktion im Authenticator-Modul die vom sektoralen IDP übertragene SessionID zur laufenden Anwendungsinstanz mit dem zur SessionID auf dem Gerät des Versicherten gespeicherten Schlüssel signieren und an den sektoralen IDP übertragen.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Unter A_24748-01

Alt:

Hinweis 2: Ein Beispielablauf für SSO Unterstützung auf Anwendungsebene innerhalb einer APP ist in Kapitele 7.4.1 dargestellt.

Neu:

Hinweis 2: Ein Beispielablauf für SSO Unterstützung auf Anwendungsebene innerhalb einer APP ist inm Kapitele 7.4.1"SSO-Unterstützung auf Anwendungsebene innerhalb einer APP" dargestellt.

Alt:

A_25870 - SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS in seinem Authenticator-Modul sicherstellen, dass ein Authorization Request mit SSO-Anforderung von einem Anwendungsfrontend kommt, bei dem der Versicherte sich bereits authentifiziert hat, um SSO-Anforderungen von nicht berechtigten Anwendungen erkennen und ablehnen zu können.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Hinweis: Ein Beispielablauf für SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP ist im Kapitel 7.4.2 dargestellt.

Geänderte Zuordnung:

A_25870 - SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS in seinem Authenticator-Modul sicherstellen, dass ein Authorization Request mit SSO-Anforderung von einem Anwendungsfrontend kommt, bei dem der Versicherte sich bereits authentifiziert hat, um SSO-Anforderungen von nicht berechtigten Anwendungen erkennen und ablehnen zu können.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Hinweis: Ein Beispielablauf für SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP ist im Kapitel 7.4.2 "SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP" dargestellt.

Alt:

A_24749-01 - Validierung gegen Nutzerzustimmung
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob für den Fachdienst, welcher die Nutzerauthentisierung angefordert hat, die Zustimmung zum SSO-Verfahren durch den Nutzer vorliegt. Eine Nutzerauthentisierung ohne Nutzerinteraktion darf nur bei Zustimmung durchgeführt werden.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Geänderte Zuordnung:

A_24749-01 - Validierung gegen Nutzerzustimmung
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob für den Fachdienst, welcher die Nutzerauthentisierung angefordert hat, die Zustimmung zum SSO-Verfahren durch den Nutzer vorliegt. Eine Nutzerauthentisierung ohne Nutzerinteraktion darf nur bei Zustimmung durchgeführt werden.

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Alt:

A_25875 - Aktive Nutzerauthentifizierung im Anwendungskontext
Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob der Nutzer sich im laufenden Anwendungskontext bereits aktiv auf gematik-loa-high authentifiziert hat.

<=, IDP-Sek, Sich.techn. Eignung: Gutachten

Neu:

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

<=, IDP-Sek, Sich.techn. Eignung: ProduktgGutachten

Änderungen in Kapitel 5.3.1 "PIN der eGK ändern"

Alt:

A_15497-03 - Authenticator-Modul: PIN der eGK ändern
Das Authenticator-Modul von sektoralen IdPs gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK ändern" gemäß TAB_FdV_156 umsetzen.

Tabelle 10: TAB_FdV_156 – PIN der eGK ändern

Tabelle 11: TAB_FdV_157 – Ablaufaktivitäten – PIN der eGK ändern

<=

Neu:

A_15497-04 - Authenticator-Modul: PIN der eGK ändern
Das Authenticator-Modul von sektoralen IDP gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK ändern" gemäß TAB_FdV_156 umsetzen.

Tabelle 10: TAB_FdV_156 – PIN der eGK ändern

Tabelle 11: TAB_FdV_157 – Ablaufaktivitäten – PIN der eGK ändern

<=

Änderungen in Kapitel 5.3.2 "PIN der eGK entsperren"

Alt:

A_15498-03 - Authenticator-Modul: PIN der eGK entsperren
Das Authenticator-Modul von sektoralen IdPs gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK entsperren" gemäß TAB_FdV_158 umsetzen.

Tabelle 12: TAB_FdV_158 – PIN der eGK entsperren

Tabelle 13: TAB_FdV_159 – Ablaufaktivitäten – PIN der eGK entsperren

<=

Neu:

A_15498-04 - Authenticator-Modul: PIN der eGK entsperren
Das Authenticator-Modul von sektoralen IdPs gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK entsperren" gemäß TAB_FdV_158 umsetzen.

Tabelle 12: TAB_FdV_158 – PIN der eGK entsperren

Tabelle 13: TAB_FdV_159 – Ablaufaktivitäten – PIN der eGK entsperren

<=

Änderungen in Kapitel 6.5.2 "Weitere Dokumente"

Neu:

Änderungen in Kapitel 7.1.4 "Detailinformationen zum App-App-Flow"

Alt:

Tabelle 16 : Body Entity Statement des Federation Master

Neu:

Tabelle 16 : Body Entity Statement des Federation Master

Alt:

Tabelle 21 : Body Entity Statement des sektoralen IDP

Neu:

Tabelle 21 : Body Entity Statement des sektoralen IDP

Alt:

signed_jwks_uri

Ablageort für weitere Schlüssel des IDP etwa die zur Signatur seiner Token. Wenn eine signed_jwks_uri im Entity Statement angegeben ist, müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+json

Neu:

signed_jwks_uri

Ablageort für weitere Schlüssel des IDP, etwa die zur Signatur seiner Token. Wenn eine signed_jwks_uri im Entity Statement angegeben ist, müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+jsonjwt

Alt:

Tabelle 27 : Parameter Pushed Authorization Request 

code

 Zu den Scopes und Claims bzgl. der Identitäten für Versicherte siehe A_22989-01 in Kapitel 4.2.4.2. 

Neu:

Tabelle 27: Parameter Pushed Authorization Request 

code

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

claims=%7B%22id_token%22%3A%7B%22amr%22
%3A%7B%22essential%22%3Atrue,%22values
%22%3A%5B%22urn%3Atelematik%3Aauth%3AeGK
%22%5D%7D,%22email%22%3A%7B%22essential
%22%3Atrue%7D%7D%7D

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

Zu den Scopes und Claims bzgl. der Identitäten für Versicherte siehe A_22989-01* inm Kapitel 4.2.4.2 "Token-Endpunkt Ausgangsdaten"

Alt:

Tabelle 29: Body des Entity Statement des Fachdienstes

Neu:

Tabelle 29: Body des Entity Statement des Fachdienstes

Alt:

signed_jwks_uri

Ablageort für weitere Schlüssel des Fachdienstes etwa die zur TLS Client Schlüssel und Zertifikate (x5c, use = sig) oder für die Verschlüsselung der ID_Token (use = "enc").

Wenn eine signed_jwks_uri im Entity Statement angegeben ist müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+json

Neu:

signed_jwks_uri

Ablageort für weitere Schlüssel des Fachdienstes etwa die zur TLS Client Schlüssel und Zertifikate (x5c, use = sig) oder für die Verschlüsselung der ID Token (use = "enc").

Wenn eine signed_jwks_uri im Entity Statement angegeben ist, müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+jsonjwt

Alt:

Tabelle 34 : Body zum Entity Statement des Federation Master über den Fachdienst

Neu:

Tabelle 34 : Body zum Entity Statement des Federation Master über den Fachdienst

Alt:

Tabelle 39 : HTTP-POST Parameter für AUTHORIZATION_CODE und den CODE_VERIFIER

Neu:

Tabelle 39 : HTTP-POST Parameter für AUTHORIZATION_CODE und den CODE_VERIFIER

Alt:

Tabelle 40 : Header-claims des ID_TOKEN des sektoralen IDP

Neu:

Tabelle 40 : Header-claims des ID_TOKEN des sektoralen IDP

Alt:

Tabelle 41: Signature Header Claims des ID_TOKEN des sektoralen IDP

Neu:

Tabelle 41: Signature Header Claims des ID_TOKEN des sektoralen IDP

Neu:

Nach Tabelle 42 wird A_22989 entfernt, da diese bereits im Kapitel 4.2.4.2 enthalten ist und durch folgenden Satz ersetzt:

Zu den Scopes und Claims bzgl. der Identitäten für Versicherte siehe A_22989-01 im Kapitel "Token-Endpunkt Ausgangsdaten".

3 Änderungen in gemSpec_IDP_FedMaster

Änderungen in Kapitel 2.1 "Allgemeiner Überblick"

Alt:

Um eine Gesamtlösung sicherzustellen, bei der Anwendungen in möglichst einfacher Weise die verschiedenen sektoralen Identity Provider nutzen können, sind in bestimmten Bereichen einheitliche Vorgaben für die technische und organisatorische Umsetzung zu erstellen:

• Einheitliche Identitätsattribute für die Nutzergruppen (Minimal claim Sets, scopes)
• Grundstruktur der Vertrauensbeziehungen der Föderierung (IDP Federation/Trust Chains)
• Einheitliche Verfahren zum Auffinden von sektoralen Identity Providern (IDP Discovery)
• Einheitliche Vertrauensniveaus (Trust Framework).

Neu:

Um eine Gesamtlösung sicherzustellen, bei der Anwendungen in möglichst einfacher Weise die verschiedenen sektoralen Identity Provider nutzen können, sind in bestimmten Bereichen einheitliche Vorgaben für die technische und organisatorische Umsetzung zu erstellen:

• Einheitliche Identitätsattribute für die Nutzergruppen (Minimal claim Sets, scopes),
• Grundstruktur der Vertrauensbeziehungen der Föderierung (IDP Federation/Trust Chains),
• Einheitliche Verfahren zum Auffinden von sektoralen Identity Providern (IDP Discovery),
• Einheitliche Vertrauensniveaus (Trust Framework).

Änderungen in Kapitel 2.3 "Akteure und Rollen"

Alt:

Tabelle 2: Akteure und Rollen

Neu:

Tabelle 2: Akteure und Rollen

Änderungen in Kapitel 3.1 "Anwendungsfälle"

Alt:

Tabelle 4: Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

Neu:

Tabelle 4: Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

Änderungen in Kapitel 3.3.1 "Akzeptanzkriterien - Entity Statement bereitstellen"

Alt:

ML-152179 - AF_10101 - Payload des JWS-Token enthält Informationen zum angefragten Teilnehmer der Föderation

Der Payload des JWS-Token enthält diese Informationen bezüglich des angefragten Teilnehmers der Föderation (siehe auch gemSpec_IDP_Sek - Anhang B - Abläufe):

• iss = URL - Identifier Federation Master
• sub = URL - Identifier des angefragten Teilnehmers
• iat = long Wert - Ausstellungszeitpunkt des Abrufs (Alle time-Werte in Sekunden seit 1970)
• exp = long Wert - Ablaufzeitpunkt der Gültigkeit des Abrufs (Alle time-Werte in Sekunden seit 1970)
• jwks = JWKS Objekt - öffentlicher Schlüssel des angefragten Teilnehmers.
• aud = URL - Identifier des anfragenden Teilnehmers. Wenn der aud-Parameter im Fetch Entity-Statement-Request des anfragenden Teilnehmers vorhanden ist, MUSS der aud Parameter in der Fetch Entity-Statement-Response vorhanden sein und genau diesen Wert annehmen.  
  

Für registrierte Relying Parties (Fachdienste) MÜSSEN zusätzlich diese Informationen im Payload des JWS-Token enthalten sein:

• scope = scope, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• claims = claims, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• redirect_uris = redirect_uris, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden

<=

Hinweis: Will eine Relying Party den Umfang der vom sektoralen IDP anforderbaren scopes oder claims erweitern oder redirect_uris ändern, so müssen diese Änderungen über den organisatorischen Registrierungsprozess laufen.

Neu:

ML-152179 - AF_10101 - Payload des JWS-Token enthält Informationen zum angefragten Teilnehmer der Föderation

Der Payload des JWS-Token enthält diese Informationen bezüglich des angefragten Teilnehmers der Föderation (siehe auch [gemSpec_IDP_Sek - Anhang B - Abläufe]):

• iss = URL - Identifier Federation Master
• sub = URL - Identifier des angefragten Teilnehmers
• iat = long Wert - Ausstellungszeitpunkt des Abrufs (Alle time-Werte in Sekunden seit 1970)
• exp = long Wert - Ablaufzeitpunkt der Gültigkeit des Abrufs (Alle time-Werte in Sekunden seit 1970)
• jwks = JWKS-Objekt - öffentlicher Schlüssel des angefragten Teilnehmers.
• aud = URL - Identifier des anfragenden Teilnehmers. Wenn der aud-Parameter im Fetch Entity-Statement-Request des anfragenden Teilnehmers vorhanden ist, MUSS der aud Parameter in der Fetch Entity-Statement-Response vorhanden sein und genau diesen Wert annehmen.  
  

Für registrierte Relying Parties (Fachdienste) MÜSSEN zusätzlich diese Informationen im Payload des JWS-Token enthalten sein:

• scopes = scopes, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• claims = claims, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• redirect_uris = redirect_uris, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden

<=

Hinweis: Will eine Relying Party den Umfang der vom sektoralen IDP anforderbaren Scopes oder Claims erweitern oder redirect_uris ändern, so müssen diese Änderungen über den organisatorischen Registrierungsprozess laufen.

Änderungen in Kapitel 4.1 "Aufbau und Inhalt des Federation Master Entity Statement"

Alt:

A_25414 - Prüfung der Entity Statements von Fachdiensten
Der Anbieter des Federation Master MUSS einen Prozess etablieren, in dem der Anbieter des Federation Master mindestens täglich die Entity Statements der Fachdienste abfragt und die Werte der in Tabelle "Prüfung der Entity Statements von Fachdiensten" aufgeführten Attribute hinsichtlich der bei der Registrierung hinterlegten Werte prüft. Stimmen die Werte nicht überein, so MUSS der Federation Master die in der Tabelle aufgeführten Maßnahmen treffen.

Tabelle 15 : Prüfung der Entity Statements von Fachdiensten

<=, IDP_FedMaster, Sich.techn. Eignung: Herstellererklärung

Hinweis 1: Das Sperren eines Fachdienstes bedeutet technisch den Ausschluss aus der Föderation. Fragt ein sektoraler IDP die Teilnehmerauskunft zu einem gesperrten Fachdienst beim Federation Master ab, so antwortet dieser gemäß [https://openid.net/specs/openid-federation-1_0.html#error_response] mit Error Code HTTP-401 invalid_client.

Neu:

A_25414-01 - Prüfung der Entity Statements von Fachdiensten
Der Anbieter des Federation Master MUSS einen Prozess etablieren, in dem der Anbieter des Federation Master mindestens täglich die Entity Statements der Fachdienste abfragt und die Werte der in Tabelle "Prüfung der Entity Statements von Fachdiensten" aufgeführten Attribute hinsichtlich der bei der Registrierung hinterlegten Werte prüft. Stimmen die Werte nicht überein, so MUSS der Federation Master die in der Tabelle aufgeführten Maßnahmen treffen.

Tabelle 15 : Prüfung der Entity Statements von Fachdiensten

<=, Anb_IDP_FedMaster, Sich.techn. Eignung: HerstellerAnbietererklärung

Hinweis 1: Das Sperren eines Fachdienstes bedeutet technisch den Ausschluss aus der Föderation. Fragt ein sektoraler IDP die Teilnehmerauskunft zu einem gesperrten Fachdienst beim Federation Master ab, so antwortet dieser gemäß   https://openid.net/specs/openid-federation-1_0.html#error_response [OpenID Federation 1.0#error_response] mit Error Code HTTP-401 invalid_client 404 not_found.

Änderungen in Kapitel 4.2 "Organisatorische Prozesse am Federation Master"

Alt:

Neu:

Alt:

Fachdienste sollten nur genau die scopes beanspruchen, die für die Ausführung ihrer Anwendungsfälle unbedingt notwendig sind. Eine differenziertere Unterscheidung in verpflichtenden Attribute (essential claims, ohne die eine Diensterbringung gar nicht möglich ist) und freiwillige Attribute (voluntary claims, ohne die eine Diensterbringung in eingeschränktem Umfang möglich ist) wird durch die Verwendung von claims ermöglicht.

Neu:

Fachdienste sollten nur genau die scopes Werte beanspruchen, die für die Ausführung ihrer Anwendungsfälle unbedingt notwendig sind. Eine differenziertere Unterscheidung in verpflichtenden Attribute (essential claims, ohne die eine Diensterbringung gar nicht möglich ist) und freiwillige Attribute (voluntary claims, ohne die eine Diensterbringung in eingeschränktem Umfang möglich ist) wird durch die Verwendung von claims ermöglicht.

Änderungen in Kapitel 5.2 "Glossar"

Alt:

Tabelle 1: Glossar

Neu:

Tabelle 2: Glossar

Änderungen in Kapitel 5.5.2 weitere Dokumente

Neu:

Tabelle 22: Weitere Dokumente

4 Änderungen in gemSpec_IDP_FD

Änderungen in Kapitel 2 "Systemüberblick"

Alt:

Fachdienste, welche sektorale IDPs der TI-Föderation zur Nutzer-Authentisierung nutzen möchten, müssen die folgenden Prozesse und Schnittstellen bedienen:

• Registrierung des Fachdienstes beim Federation Master (organisatorischer Prozess gemäß [gemSpec_IDP_FedMaster]), sowie der verwendeten öffentlichen Schlüssel für die Signatur von Entity Statements und Mitteilung der benötigten scopes bzw. claims (Key/Value-Paare im Payload eines JWT)
• Veröffentlichung ihres signierten Entity Statements (siehe 4.5).

Neu:

Fachdienste, welche sektorale IDPs der TI-Föderation zur Nutzer-Authentisierung nutzen möchten, müssen die folgenden Prozesse und Schnittstellen bedienen:

• Registrierung des Fachdienstes beim Federation Master (organisatorischer Prozess gemäß [gemSpec_IDP_FedMaster]), sowie der verwendeten öffentlichen Schlüssel für die Signatur von Entity Statements und Mitteilung der benötigten scopes bzw. claims (Key/Value-Paare im Payload eines JWT)
• Veröffentlichung ihres signierten Entity Statements (siehe 4.5).

Änderungen in Kapitel 4.1 "Registrierung des Fachdienstes beim Federation Master"

Alt:

Fachdienstbetreiber müssen ihren Authorization Server beim Federation Master registrieren. Die Registrierung erfolgt als organisatorischer Prozess, bevor ein Fachdienst an den vom föderierten Identitätsmanagement (IDM) angebotenen Authentifizierungsprozessen teilnehmen kann. Erst nach erfolgter Registrierung, bei der die Adresse des Fachdienstes bzw. seines Authorization Servers, seine öffentlichen Schlüssel sowie die verwendeten scopes und claims angegeben wurden, können sektorale Identity Provider ID_TOKEN für den Fachdienst ausstellen.

Neu:

Fachdienstbetreiber müssen ihren Authorization Server beim Federation Master registrieren. Die Registrierung erfolgt als organisatorischer Prozess, bevor ein Fachdienst an den vom föderierten Identitätsmanagement (IDM) angebotenen Authentifizierungsprozessen teilnehmen kann. Erst nach erfolgter Registrierung, bei der die Adresse des Fachdienstes bzw. seines Authorization Servers, seine öffentlichen Schlüssel sowie die verwendeten scopes und claims angegeben wurden, können sektorale Identity Provider ID_TOKEN für den Fachdienst ausstellen.

Alt:

Neu:

Alt:

Hinweis: claims definieren konkrete Key/Value-Paare, die als Payload eines JWT codiert werden. Scopes fassen ein oder mehrere claims als Gruppe im Authorization Request zusammen. Ein vereinbarter scope sagt aus, welche Key/Value-Paare im Payload erwartet werden. Die Vereinbarung wird zwischen dem Fachdienst und dem Federation Master während der Registrierung des Fachdienstes getroffen. Im Rahmen einer Authentifizierung fragen Authorization Server den jeweils benötigten scope bzw. claims an, die im Rahmen des ID_TOKEN vom sektoralen Identity Provider bestätigtwerden.

Neu:

Hinweis: claims definieren konkrete Key/Value-Paare, die als Payload eines JWT codiert werden. Ein scopes fassten ein oder mehrere claims als Gruppe im Authorization Request zusammen. Ein vereinbarter scope sagt aus, welche Key/Value-Paare im Payload erwartet werden. Die Vereinbarung wird zwischen dem Fachdienst und dem Federation Master während der Registrierung des Fachdienstes getroffen. Im Rahmen einer Authentifizierung fragen Authorization Server den jeweils benötigten scope bzw. claims an, die im Rahmen des ID_TOKEN vom sektoralen Identity Provider bestätigt werden.

Änderungen in Kapitel 4.2 "Übergreifende Festlegungen"

Alt:

Der Payload eines JWT beinhaltet Key/Value-Paare, welche in einem oder mehreren scopes definiert werden. Inhalte eines scopes sind mehrere Attribute, welche der sektorale IDP auf Basis der vorgetragenen Identität bestätigen kann.

Die scopes beinhalten die für diesen Fachdienst abgestimmten Attribute (die scopes werden pro Fachdienst in einem organisatorischen Prozess gesoert vom jeweiligen Fachdienst mit dem Federation Master abgestimmt) und den Wertebereich, welchen diese annehmen können.

Neben den im Standard vorgesehenen Attributen (siehe openid-connect-core-1_0.html#IDToken) erwarten Fachdienste in der Regel weitere Informationen, wie zum Beispiel Vorname, Name, Rolle und KVNR des Nutzers. Siehe hierzu auch [gemSpec_IDP_Sek] Kapitel: "Token-Endpunkt Ausgangsdaten".

Neu:

Der Payload eines JWT beinhaltet Key/Value-Paare, welche in einem oder mehreren scopesScopes definiert werden. Inhalte eines scopesScopes sind mehrere Attribute, welche der sektorale IDP auf Basis der vorgetragenen Identität bestätigen kann.

Die scopesScopes beinhalten die für diesen Fachdienst abgestimmten Attribute (die scopesScopes werden pro Fachdienst in einem organisatorischen Prozess gesondert vom jeweiligen Fachdienst mit dem Federation Master abgestimmt) und den Wertebereich, welchen diese annehmen können.

Neben den im Standard vorgesehenen Attributen (siehe [OpenID Connect Core 1.0#IDToken]) erwarten Fachdienste in der Regel weitere Informationen, wie zum Beispiel Vorname, Name, Rolle und KVNR des Nutzers. Siehe hierzu auch [gemSpec_IDP_Sek] Kapitel: "Token-Endpunkt Ausgangsdaten".

Alt:

Neu:

A_23036-02 - Inhalte des "scopes" für Versicherte
Fachdienste MÜSSEN bei ihrer Registrierung am Federation Master sicherstellen, dass ausschließlich die fachlich benötigten Attribute aus der in [gemSpec_IDP_Sek] Kapitel: "Token-Endpunkt Ausgangsdaten" definierten Auswahl als scopes und claims beantragt werden.

<=

Alt:

Neu:

Alt:

Neu:

Änderungen in Kapitel 4.5 "Verifikation des "ID_TOKEN""

Alt:

Neu:

A_22860-02 - Prüfung benötigter "scopes" und "claims"
Fachdienste MÜSSEN erhaltene ID_TOKEN auf das Vorhandensein der benötigten scopes und claims überprüfen.