Terminologie/Glossar

Einzelne Information über eine Entität

Eine Anwendung, die geschützte Ressourcenanforderungen im Namen des Ressourceneigentümers und mit seiner Autorisierung durchführt. Der Begriff „Client“ impliziert keine besonderen Implementierungsmerkmale (z. B. ob die Anwendung auf einem Server, einem Desktop oder anderen Geräten ausgeführt wird).

Im Kontext der TI-Föderation ist das Anwendungsfrontend einer Fachanwendung der (OAuth)-Client bezüglich des Authorization-Servers bzw. des Resourceserver der Fachanwendung.

Der Authorization-Server der Fachanwendung ist gleichzeitig auch der (OIDC)-Client bezüglich des sektoralen IDP.

Die code challenge wird vom Code Verifier abgeleitet und bei einer Autorisierungsanfrage an den Autorisierungsserver gesendet.  Der Autorisierungsserver  merkt sich die code challenge zu dem von ihm ausgegeben Authorization Code. Beim Eintausch des Authorization Code gegen ein Access Token wird durch den Code Verifier die Legitimität der Anfrage verifiziert.

Die code challenge method ist die Methode, mit der die code challenge aus dem code verifier erstellt wurde. 

Code Verifier ist eine kryptografisch zufällige Zeichenfolge. Bei einer Autorisierungsanforderung wird letztlich gegen diese Zeichenfolge validiert.

Daten, die als Beweis für das Recht zur Nutzung einer Identität oder anderer Ressourcen präsentiert werden.

Nutzende natürliche Person (Mensch)

Entität

Etwas, das eine separate und eindeutige Existenz hat und das in einem Kontext identifiziert werden kann. Alle Entitäten in einem OpenID Connect-Verbund haben einen global eindeutigen Bezeichner → Entitätsbezeichner

Ein URI, der global eindeutig ist und an eine Entität gebunden ist.

Ein Entity Statement - Entitätsaussage - wird von einer Entität ausgegeben, die sich auf eine Subjekt-Entität und Blatt-Entitäten bezieht. Ein Entitätsstatement ist immer ein signiertes JWT.

Fachdienste bzw. Fachanwendungen sind die Anwendungen, mit denen ein Nutzer arbeiten möchte. So sind z. B. E-Rezept und die elektronische Patientenakte TI-Fachanwendungen. Ebenso sind die digitalen Gesundheitsanwendungen (DiGA) Fachdienste. Die Fachdienste/Fachanwendungen benötigen eine Nutzerauthentifizierung um sicherzustellen, dass ein Nutzer die Anwendung überhaupt nutzen darf. Im OAuth/OIDC-Kontext besteht der Fachdienst aus einem Authorizationserver (zur Abwicklung der Authentifizierung über einen IDP) und der eigentlichen Fachanwendung (mit Daten und Prozessen).  Aus OAuth/OIDC Sicht agiert der Authorizationserver als Relying Party , die eigentliche Fachanwendung als Ressource Server. Für die Nutzerinteraktion verfügen Fachdienste bzw. Fachanwendungen über User Interfaces (UI) in Form von nativen Apps, Web-Frontends oder Desktopanwendungen.

Allgemeiner Begriff für die IDP der Föderation. Konkret ist jeder IDP der Föderation für die Verwaltung von Identitäten bestimmter Sektoren (also = sektoraler IDP) zuständig.

Die GesundheitsID ist die digitale Identität im Gesundheitswesen für Versicherte, welche durch die eigene Krankenversicherung bereitgestellt wird. Sie dient zur Anmeldung an TI-Anwendungen und weiteren versorgungsrelevanten Fachanwendungen und kann perspektivisch auch als Versicherungsnachweis - analog zur elektronischen Gesundheitskarte - verwendet werden.

Hardware Security Module, Hardware-Sicherheitsmodul

JSON Web Token (JWT), welches Eigenschaften zur angefragten Identität und ggf. weitere Informationen enthält.

Intermediäre Entität: Eine Entität, die eine Entitätserklärung ausstellt, die zwischen den vom Vertrauensanker und der Blattentität in einer Vertrauenskette ausgestellten Erklärungen liegt.

(Wird in der aktuellen Architektur nicht verwendet)

Ausstellende Entität für ein Token oder Entity Statement (über sich selbst oder eine andere Entität - dann als Subject bezeichnet)

OpenID Connect Core 1.0 incorporating errata set 1

OpenID Connect Federation 1.0 (draft) 

Blatt-Entität: Eine Entität, die durch ein bestimmtes Protokoll definiert ist, z. B. OpenID Connect Relying Party oder Provider.

OAuth 2.0-Autorisierungsserver, der in der Lage ist, den Endbenutzer zu authentifizieren und einer vertrauenden Seite Informationen zur Authentifizierung und zum Endbenutzer bereitzustellen.

Beim Pushed Authorization Request werden im Vorfeld des eigentlichen OpenID Authorization Code Flow die Parameter direkt zwischen RP und OP ausgetauscht und diese gegenseitig Authentisiert.

Proof Key for Code Exchange ist eine Erweiterung des Autorisierungscodeflusses, um CSRF- und Authorization- Code-Injection-Angriffe zu verhindern. Bei dieser Technik erstellt der Client zunächst bei jeder Autorisierungsanforderung ein Geheimnis und verwendet dieses Geheimnis dann erneut, wenn er den Autorisierungscode gegen ein Access Token austauscht. 

Refresh Token sind credentials, welche zum Abrufen von Access Token verwendet werden. Refresh Token werden vom Autorisierungsserver an den Client ausgegeben und verwendet, um ein neues Access Token zu erhalten, wenn das aktuelle Access Token ungültig wird oder abläuft, oder um zusätzliche Access Token mit identischem oder engerem Umfang zu erhalten. Access Token können eine kürzere Lebensdauer haben und weniger Berechtigungen als vom Ressourceneigentümer autorisiert. Das Ausstellen eines Refresh Token ist optional. 

OAuth 2.0-Clientanwendung, die eine Endbenutzerauthentifizierung und Informationen von einem OpenID-Anbieter erfordert.

URL, die auf eine Ressource verweist, welche vom Autorisierungsserver abrufbar sein muss.

Entität, die Zugriff auf eine geschützte Ressource gewähren kann. Wenn der Ressourceneigentümer eine Person ist, wird er als Endbenutzer bezeichnet.

Der Server, der die geschützten Ressourcen hostet und in der Lage ist, Anforderungen für geschützte Ressourcen mithilfe von Zugriffstoken zu akzeptieren und darauf zu antworten.

Jeder IDP verwaltet die Identitäten zu einem bestimmten Sektor. So verwalten die IDPs der Krankenkassen beispielsweise den Sektor der Versicherten, während andere IDPs die verschiedenen Sektoren der Leistungserbringer abdecken können.

Entität über welche ein Token oder Entity Statement ausgestellt wurde und für welche die darin genannten Informationen gelten. 

OpenID Connect Core 1.0 incorporating errata set 1

OpenID Connect Federation 1.0 (draft) 

Bezeichnung für eine bestimmte Berechtigung (OAuth2) oder einen Satz von Informationen (OpenID) welche angefragt werden.

OpenID Connect Core 1.0 incorporating errata set 1

The OAuth 2.0 Authorization Framework

Vertrauensanker: Eine Entität, die eine vertrauenswürdige dritte Partei darstellt. (Der Federation Master)