A_23413 - Entity Statement vom Federation Master abrufen

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

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

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

A_28848 - Validierung der Vertrauenskette eines TI-Föderation-Teilnehmers

Teilnehmer der TI-Föderation, welche mit anderen Teilnehmern der TI-Föderation kommunizieren wollen, MÜSSEN das Entity Statement des anderen TI-Föderation-Teilnehmers abrufen und gemäß der Regeln [OpenID Federation 1.1] ("Entity Statement Validation") validieren, sowie die Vertrauenskette gemäß [OpenID Federation 1.1] ("Resolving the Trust Chain and Metadata") prüfen. Der Abruf des Entity Statement sollte alle 12h und MUSS innerhalb von 24h erfolgen.
[<=]

A_29019 - Abruf eines Subordinate Statement abweichend von OpenID Federation 1.1 (befristet)

Der Abruf eines Subordinate Statement eines Teilnehmers zu einem anderen Teilnehmer bei dessen Superior Entity MUSS abweichend zu [OpenID Federation 1.1]  ("Fetch Subordinate Statement Request") ein HTTP-GET Request mit folgenden Parametern an den federation_fetch_endpoint der Superior Entity sein:

Tabelle 2: Teilnehmer Validierung Abfrage - Request-Parameter

Attribut	Werte / Typ	Anmerkung
iss	string, URL nach [RFC1738]	Identifier (iss) der Subordinate Entity (Federation Master oder Intermendiate-Entity), bei welcher der Teilnehmer (sub) registriert ist.
sub	string, URL nach [RFC1738]	Identifier (iss) des angefragten Teilnehmers aus dessen Entity Statement

Hinweis: Eine Umstellung auf den aktuellen Standard entsprechend [OpenID Federation 1.1 ] ("Fetch Subordinate Statement Request") kann erst erfolgen, wenn die API des Federation Master angepasst wurde. [<=]

A_23133 - Maximale Gültigkeitsdauer der Entity Statements bekannter Fachdienste

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

A_28857 - Maximale Gültigkeitsdauer und regelmäßige Erneuerung des Entity Statement eines TI-Föderation-Teilnehmers

Teilnehmer der TI-Föderation MÜSSEN ihr Entity Statement bei Änderungen oder vor dem zeitlichen Ablaufen neu ausstellen. Die maximale Gültigkeitsdauer - gegeben durch die Differenz der Attributwerte exp-iat - darf 24 Stunden nicht überschreiten. [<=]

A_22662 - Registrierung beim Federation Master durch organisatorischen Prozess

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

A_28879 - Registrierung von Teilnehmern in der TI-Föderation durch organisatorischen Prozess

Ein Teilnehmer der TI-Föderation MUSS seinen öffentlichen Schlüssel für die Signatur des selbst-signierten Entity Statement (federation entity signing key) über einen organisatorischen Prozess bei der Superior Entity (Federation Master oder Intermediate) bekannt machen, bei welcher der Teilnehmer als Subordinate Entity registriert werden soll. Nach erfolgreicher Registrierung wird dem Teilnehmer der öffentliche Schlüssel übermittelt, mit dem das Entity Statement des Federation Master signiert ist (federation entity signing key). Der Teilnehmer MUSS diesen Schlüssel speichern und zur Validierung einer Vertrauenskette gemäß A_28848* verwenden. [<=]

A_22643-01 - Entity Statement des sektoralen IDP

Der sektorale IDP MUSS ein selbst signiertes Entity Statement gemäß [OpenID Federation 1.0#name-entity-statement] bereitstellen und im Internet verfügbar machen. Das Entity Statement MUSS mindestens die in der folgenden Tabelle aufgeführten Metadaten enthalten: 

Tabelle 3: Header des Entity Statement des sektoralen IDP

Name	Werte / Wertebereich
alg	string, zulässiger Wert "ES256"
kid	string Es wird empfohlen, den JWK Thumbprint gemäß [RFC7638] als kid zu verwenden.
typ	string zulässiger Wert "entity-statement+jwt"

Tabelle 4 : Allgemeine Attribute  im well-known-Dokument des sektoralen IDP

Name	Werte / Wertebereich
iss	string, URL nach [RFC1738]
sub	string, URL nach [RFC1738]
iat	number, Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
exp	number, Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
jwks	Set von JWK [RFC7517]
authority_hints	[string] zulässiger Wert: iss aus dem Entity Statement des Federation Master
metadata	string, zulässiger Wert: "openid_provider"

Tabelle 5 :  Attribute des Metadatenblocks openid_provider im well-known-Dokument des sektoralen IDP

Name	Werte
issuer	string, URL nach [RFC1738]
signed_jwks_uri (*)	string, URL nach [RFC1738]
jwks (*)	Set von JWK [RFC7517]
authorization_endpoint	string, URL nach [RFC1738]
token_endpoint	string, URL nach [RFC1738]
pushed_authorization_request_endpoint	string, URL nach [RFC1738]
client_registration_types_supported	[string] zulässiger Wert: "automatic"
subject_types_supported	[string] zulässiger Wert: "pairwise"
response_types_supported	[string] zulässiger Wert: "code"
scopes_supported	[string],  Wertebereich: "openid", "<weitere Scopes nach A_22989*>"
claims_supported	[string],  Wertebereich: "<Claims nach A_22989*>"
claims_parameter_supported	boolean, Wertebereich: true/false
response_modes_supported	[string] zulässiger Wert: "query"
grant_types_supported	[string] zulässiger Wert: "authorization_code"
require_pushed_authorization_requests	boolean, Wertebereich: true/false
token_endpoint_auth_methods_supported	[string] erforderlicher Wert: "self_signed_tls_client_auth"
id_token_signing_alg_values_supported	[string] erforderlicher Wert: "ES256"
id_token_encryption_alg_values_supported	[string] erforderlicher Wert: "ECDH-ES"
id_token_encryption_enc_values_supported	[string] erforderlicher Wert: "A256GCM"
user_type_supported	[string] zulässiger Wert: "IP" (Insured Person)
ti_features_supported {
id_token_version_supported	[string] zulässige Werte in Liste: "1.0.0", "2.0.0"

Tabelle 6 : Attribute des Metadatenblocks federation_entity im well-known-Dokument des sektoralen IDP

(*) - gemäß [OpenID Federation 1.0] darf der Metadatenblock nur entweder signed_jwks_uri oder jwks enthalten.

Name	Werte / Wertebereich
organization_name	String (max. 128 Zeichen) Wertebereich: ^[ÄÖÜäöüß\w\ \-\.\&\+\*\/]{1,128}$

[<=]

A_22643-02 - Entity Statement des sektoralen IDP

Der sektorale IDP MUSS ein selbst signiertes Entity Statement gemäß [OpenID Federation 1.1] ("Entity Statement") bereitstellen und im Internet verfügbar machen. Das Entity Statement MUSS mindestens die in der folgenden Tabelle aufgeführten Metadaten enthalten: 

Tabelle 7: Header des Entity Statement des sektoralen IDP

Name	Werte / Wertebereich
alg	string, zulässiger Wert "ES256"
kid	string, UUID7-Format [RFC9562#name-uuid-version-7] Es wird empfohlen, den JWK Thumbprint gemäß [RFC7638] als kid zu verwenden.
typ	string, zulässiger Wert "entity-statement+jwt"

Tabelle 8 : Allgemeine Attribute  im well-known-Dokument des sektoralen IDP

Name	Werte / Wertebereich
iss	string, URL nach [RFC1738]
sub	string, URL nach [RFC1738]
iat	number, Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
exp	number, Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
jwks	Set von JWK [RFC7517]
authority_hints	[string] zulässige Werte gemäß [OpenID Federation 1.1]  ("Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements") - authority_hints
metadata	JSON Object, erforderlicher Wert: "openid_provider"

Tabelle 9 : Attribute des Metadatenblocks openid_provider im well-known-Dokument des sektoralen IDP

Name	Werte
issuer	string, URL nach [RFC1738]
signed_jwks_uri (*)	string, URL nach [RFC1738]
jwks (*)	Set von JWK [RFC7517]
authorization_endpoint	string, URL nach [RFC1738]
token_endpoint	string, URL nach [RFC1738]
pushed_authorization_request_endpoint	string, URL nach [RFC1738]
organization_name	string (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - organization_name)  Wertebereich: ^[à-üÀ-Üß\w\ \-\.\+\*\/]{1,128}$
display_name	string (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - display_name)  Wertebereich: ^[à-üÀ-Üß\w\ \-\.\+\*\/]{1,128}$
keywords	[string] (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - keywords)  erforderliche Werte: "product_type_version:<von der gematik zugelassene Produkttyp-Version>" "product_type:<von der gematik zugelassener Produkttyp>"
contacts	[string] (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - contacts)  erforderlicher Wert in Liste: "<E-Mail-Adresse für Supportanfragen>"
logo_uri	string, URL nach [RFC1738] zulässiger Wert: <URL>*.png
client_registration_types_supported	[string] zulässiger Wert: "automatic"
subject_types_supported	[string] zulässiger Wert: "pairwise"
response_types_supported	[string] zulässiger Wert: "code"
scopes_supported	[string],  Wertebereich: "openid", "<weitere Scopes nach A_22989*>"
claims_supported	[string],  Wertebereich: "<Claims nach A_22989*>"
claims_parameter_supported	boolean, Wertebereich: true/false
response_modes_supported	[string] zulässiger Wert: "query"
grant_types_supported	[string] zulässiger Wert: "authorization_code"
require_pushed_authorization_requests	boolean, Wertebereich: true/false  zulässiger Wert: true
token_endpoint_auth_methods_supported	[string] erforderlicher Wert: "self_signed_tls_client_auth"
id_token_signing_alg_values_supported	[string] erforderlicher Wert: "ES256"
id_token_encryption_alg_values_supported	[string] erforderlicher Wert: "ECDH-ES"
id_token_encryption_enc_values_supported	[string] erforderlicher Wert: "A256GCM"
user_type_supported	[string] zulässiger Wert: "IP" (Insured Person)
ti_features_supported {
id_token_version_supported	[string] zulässige Werte in Liste: "1.0.0", "2.0.0"

(*) - gemäß [OpenID-Federation 1.0 ] - "Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata" darf der Metadatenblock nur entweder signed_jwks_uri oder jwks enthalten.

[<=]

A_22710 - Vorlaufzeit bei geplantem Schlüsselwechsel

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

A_28859 - Vorlaufzeit bei geplantem Schlüsselwechsel Signaturschlüssel für Entity Statements

Im Rahmen eines geplanten Schlüsselwechsels der Signaturschlüssel MÜSSEN Teilnehmer der TI-Föderation den neuen öffentlichen Signaturschlüssel mindestens 24 Stunden vor der Verwendung im  jwks-Schlüsselsatz im Entity Statement zusätzlich zum aktuell gültigen Signaturschlüssel veröffentlichen. Dieser Signaturschlüssel ist der neue Schlüssel, mit dem der Teilnehmer sein Entity Statement (federation entity signing key) frühestens 24 Stunden nach dieser Veröffentlichung signiert. Der Schlüsselwechsel sollte entsprechend [OpenID Federation 1.1] ("Updating Metadata, Key Rollover, and Revocation") erfolgen.

Hinweis: Nicht betroffen von dieser Anforderung sind kurzfristig notwendige Schlüsselwechsel, z. B. aufgrund von Sicherheitsvorfällen. Diese Maßnahmen sind beispielsweise über Security Incidents abzuwickeln. Die Bearbeitung solcher kurzfristigen Schlüsselwechsel muss die Aktualisierung beim Federation Master bzw. Intermediate mit berücksichtigen, da es ansonsten zu Verarbeitungsfehlern wegen ungültiger Schlüssel kommen kann. [<=]

A_27988 - Bekanntgabe von Änderungen im Entity Statement - Anbieter sek IDP KTR

Der Anbieter sektoraler IDP KTR MUSS geplante Änderungen der folgenden Claims im Entity Statement vor deren Veröffentlichung bei dem Federation Master über einen organisatorischen Prozess beantragen:

• Änderungen des Schlüsselsets, mit dem das Entity Statement signiert wird - jwks,
• Änderungen des in der TI-Föderation propagierten Organisationsnamens - federation_entity.organization_name.

[<=]

A_22650 - automatische Registration von Fachdiensten

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

A_22650-01 - Automatische Registrierung von Fachdiensten

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

A_22655-02 - Signatur des "ID Token" des sektoralen IDP

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

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

A_22655-03 - Signatur des "ID Token" des sektoralen IDP

Der sektorale IDP MUSS die ID Token unter Verwendung eines privaten Schlüssels, der zu einem direkt unter openid_provider.jwk im Entity Statement stehenden oder unter openid_provider.signed_jwks_uri referenzierten öffentlichen Schlüssel gehört, signieren [OpenID Federation 1.1].

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