diff --git a/docs/details/authentication/cli.md b/docs/details/authentication/cli.md
index bc634a558fd2bb2759a6d8fb7102f94f77e9fbc9..2046d4cd17504380243466462a0a2bee3147a4b3 100644
--- a/docs/details/authentication/cli.md
+++ b/docs/details/authentication/cli.md
@@ -122,7 +122,7 @@ Wenn ein JWT zum Abrufen von Einreichungen generiert werden soll, kann auf den P
$ fitconnect get_jwt receiver-config.json
```
-Als Antwort erhält man einen (vom Authentifizierungsserver via OAuth2 Client Credentials Flow abgerufenen) JWT, welchen man zur Authentifizierung beim Abrufen von Einreichungen verwenden kann.
+Als Antwort erhält man einen (vom Autorisierungsserver via OAuth2 Client Credentials Flow abgerufenen) JWT, welchen man zur Authentifizierung beim Abrufen von Einreichungen verwenden kann.
```bash
$ curl -i \
diff --git a/docs/details/authentication/sender.md b/docs/details/authentication/sender.md
index f6b22e5af2455827692c65cdbce9a6c66580bb1c..003ad8605a3345cc3c0077f66e916a869110d8b3 100644
--- a/docs/details/authentication/sender.md
+++ b/docs/details/authentication/sender.md
@@ -1,44 +1,41 @@
-# Authentifizierung von antragssendenden Systemen
+# Authentifizierung von sendenden Systemen
Treten die Schlüsselwörter "MUSS"/"MÜSSEN", "DARF NICHT"/"DÜRFEN NICHT", "SOLLTE"/"SOLLTEN", "SOLLTE NICHT"/"SOLLTEN NICHT" und "KANN"/"KÖNNEN" in Großbuchstaben auf, handelt es sich um Implementierungsvorgaben, die entsprechen den Begriffen "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" und "MAY" gemäß [RFC 2119](https://tools.ietf.org/html/rfc2119) zu interpretieren sind.
-Die Authentifizierung von antragssendenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Im Folgenden sollen die nötigen Schritte zur Registrierung und zum Zugriff auf die Schnittstelle des FIT-Connect Zustelldienstes beschrieben werden. Dieses Dokument dokumentiert die implementierten Authentifizierungsmechanismen und macht Vorgaben zur Implementierung der Authentifizierung von antragssendenden Systemen. Bei der Umsetzung der Authentifizierung kann darüber hinaus auf das vom Projekt FIT-Connect bereitgestellte Software Development Kit (SDK) zurückgegriffen werden, dass die Vorgaben aus diesem Dokument umsetzt bzw. bei deren Umsetzung unterstützt.
+Die Authentifizierung von sendenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Im Folgenden sollen die nötigen Schritte zur Registrierung und zum Zugriff auf die Schnittstelle des FIT-Connect Zustelldienstes beschrieben werden. Dieses Dokument dokumentiert die implementierten Authentifizierungsmechanismen und macht Vorgaben zur Implementierung der Authentifizierung von sendenden Systemen. Bei der Umsetzung der Authentifizierung kann darüber hinaus auf das vom Projekt FIT-Connect bereitgestellte Software Development Kit (SDK) zurückgegriffen werden, dass die Vorgaben aus diesem Dokument umsetzt bzw. bei deren Umsetzung unterstützt.
<img src="/images/oauth/JWT_konzept.png" alt="Grafik: JWT Konzept" width="400"/>
## Schritt 1: Registrierung
+Jedes sendende System (z.B. ein Online-Antragsservice) muss bei FIT-Connect als API-Client registriert sein, um über FIT-Connect Anträge einreichen zu können. Bei der Registrierung eines sendenden Systems wird festgelegt, welche Anträge das System über welche Domains ausspielen darf. Vor der Registrierung eines sendenden Systems muss zunächst ein kryptographisches Schlüsselpaar durch das sendende System erzeugt werden (im Folgenden: Onlineservice-Schlüsselpaar). Der öffentliche Schlüssel (Public Key) dieses Schlüsselpaares wird anschließend bei der Registrierung im Self-Service-Portal hinterlegt. Zur Generierung des Schlüsselpaares kann auf das bereitgestellte [Kommandozeilentool zurückgegriffen werden](https://pypi.org/project/fitconnect-cli/). Bei erfolgreicher Registrierung erhält jedes sendende System OAuth2-Zugangsdaten für den Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`).
-Jedes antragssendende System (z.B. ein Online-Antragsservice) muss bei FIT-Connect als API-Client registriert sein, um über FIT-Connect Anträge einreichen zu können. Bei der Registrierung eines antragssendenden Systems wird festgelegt, welche Anträge das System über welche Domains ausspielen darf. Vor der Registrierung eines antragssendenden Systems muss zunächst ein kryptographisches Schlüsselpaar durch das antragssendende System erzeugt werden (im Folgenden: Onlineservice-Schlüsselpaar). Der öffentliche Schlüssel (Public Key) dieses Schlüsselpaares wird anschließend bei der Registrierung im Self-Service-Portal hinterlegt. Zur Generierung des Schlüsselpaares kann auf das bereitgestellte [Kommandozeilentool zurückgegriffen werden](https://pypi.org/project/fitconnect-cli/). Bei erfolgreicher Registrierung erhält jedes antragssendende System OAuth2-Zugangsdaten für den Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`).
-
-Bei der Registrierung eines antragssendenden Systems als API-Client über das Self-Service-Portal müssen die folgenden Informationen hinterlegt werden:
+Bei der Registrierung eines sendenden Systems als API-Client über das Self-Service-Portal müssen die folgenden Informationen hinterlegt werden:
- Freigegebene Domains, von denen der Online-Antragsservice Formulare übermittelt
- Eine Liste an [Zustellberechtigungs-Scopes](./scopes.md), die definiert, an welche Zustellpunkte Anträge durch den registrierten API-Client übermittelt werden dürfen.
- Der Public Key des Onlineservice-Schlüsselpaar
-## Schritt 2: Ausstellung von Berchtigungstokens für Onlineservices (Onlineservice-Token)
-
-Wenn ein Online-Antragsservice einer Antragsteller:in ermöglichen möchte, einen Antrag an die FIT-Connect Antrags-API zu übermitteln, muss dieser zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server ein Berechtigungstoken (im Folgenden "Onlineservice-Token") nach dem Standard *JSON Web Token* gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519)) abrufen. Dieser vom OAuth-Server signierte Onlineservice-Token enthält den Public-Key des Online-Antragsdienstes, der bei der Registrierung im Self-Service-Portal festgelegt wurde. Aus Sicht von API-Clients (antragssendende und -empfangende Systeme) sind die Inhalte dieses Tokens gemäß OAuth-Spezifikation als bedeutungslos anzusehen und SOLLTEN daher NICHT interpretiert werden. Eine Prüfung des Onlineservice-Token auf Korrektkeit und Gültigkeit erfolgt ausschließlich durch den Zustelldienst.
-
-### Payload des Onlineservice-Tokens
+## Schritt 2: Ausstellung von Berechtigungstokens für Onlineservices (Access Token)
+Wenn ein Online-Antragsservice einer Antragsteller:in ermöglichen möchte, einen Antrag an die FIT-Connect Antrags-API zu übermitteln, muss dieser zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server einen Berechtigungstoken (im Folgenden "Access Token") nach dem Standard *JSON Web Token* gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519)) abrufen. Dieser vom OAuth-Server signierte Access Token enthält den Public-Key des Online-Antragsdienstes, der bei der Registrierung im Self-Service-Portal festgelegt wurde. Aus Sicht von API-Clients sind die Inhalte des Tokens gemäß OAuth-Spezifikation als bedeutungslos anzusehen und SOLLTEN daher NICHT interpretiert werden. Eine Prüfung des Access Token auf Korrektheit und Gültigkeit erfolgt ausschließlich durch den Zustelldienst.
-Der hier beschriebene Payload des Onlineservice-Tokens dient lediglich der Dokumentation/Spezifikation. Antragssendende Systeme müssen den Payload des Tokens nicht auswerten oder interpretiern können.
-Im Payload des signierten Onlineservice-Token werden vom Authorisierungsdienst die folgenden [standartisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt:
+### Payload des Access Tokens
+Der hier beschriebene Payload des Access Tokens dient lediglich der Dokumentation/Spezifikation. Sendende Systeme müssen den Payload des Tokens nicht auswerten oder interpretieren können.
+Im Payload des signierten Access Token werden vom Autorisierungsdienst die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt:
| Feld | Inhalt | **Erläuterung** |
| --------------- | --------------------------------------- | --------------- |
| `iat` | Unix Timestamp | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp |
| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 24 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
-| `iss` (Issuer) | *URL des Authentifizierungsservers* | Die URL des Authentifizierungsservers, der das Token ausgestellt hat. |
-| `sub` (Subject) | ID des Onlineservice | Wird bei der Registrierung des Online-Antragsdienstes im Self-Service-Portal durch den Autorisierungsdienst festgelegt und dient zur Identifizierung des antragssendenden Systems |
-| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
+| `iss` (Issuer) | *URL des Autorisierungsservers* | Die URL des Autorisierungsservers, der das Token ausgestellt hat. |
+| `sub` (Subject) | ID des Onlineservice | Wird bei der Registrierung des Online-Antragsdienstes im Self-Service-Portal durch den Autorisierungsdienst festgelegt und dient zur Identifizierung des sendenden Systems |
+| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
| `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der [Zustellberechtigungs-Scopes](./scopes.md), für die der Token eine Übermittlung erlaubt, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Die jeweiligen Zustellberechtigungs-Scopes werden im Self-Service-Portal bei der Registrierung des API-Client festgelegt. |
| `domains` | *Liste von Domains* | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann, separiert mit Leerzeichen (Subdomains müssen explizit aufgeführt werden) |
-| `publicKey` | *Public Key des Onlineservice* | Der zum Schlüsselpaar des Online-Antragsservice gehörige Public Key, der dem Online-Antragsdienst bei der Registrierung im Self-Service-Portal zugeordnet wurde, im JSON Web Key-Format gemäß [RFC-7517](https://tools.ietf.org/html/rfc7517) |
-| `token_type` | `sender` | Gibt an, das es sich um einen Token für ein antragssendendes System (typischerweise einen Onlineservice) handelt. |
+| `cnf` | *Public Key des Onlineservice* | Der Confirmation-Claim beinhaltet den zum Schlüsselpaar des Online-Antragsservice gehörigen Public Key, der dem Online-Antragsdienst bei der Registrierung im Self-Service-Portal zugeordnet wurde. Der Public Key wird gemäß [RFC 7800, Abschnitt 3.2](https://datatracker.ietf.org/doc/html/rfc7800#section-3.2), im Feld `jwk` des `cnf`-Claims im JSON Web Key-Format gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517) abgelegt. |
+| `token_type` | `sender` | Gibt an, das es sich um einen Token für ein sendendes System (typischerweise einen Onlineservice) handelt. |
-**Beispiel-Payload eines Onlineservice-Token**
+**Beispiel-Payload eines Access Token**
```json
{
@@ -47,160 +44,165 @@ Im Payload des signierten Onlineservice-Token werden vom Authorisierungsdienst d
"iss": "https://auth.fit-connect.example.com",
"sub": "639c5be8-eb9c-4741-834e-4ad11629898a",
"jti": "1e078cd2-4717-4285-8746-91b62247eb60",
- "scope": "leika:99108008252000 leika:99108008252000+region:08110000",
+ "scope": "send:region:DE08115 send:region:DE12+send:servicetype-leika:99108008252000",
"domains": "example.com sub.example.com",
- "publicKey": {
- "kty": "RSA",
- "e": "AQAB",
- "key_ops": ["verify"],
- "alg": "PS512",
- "n": "...Public Key..."
+ "cnf": {
+ "jwk": {
+ "kty": "RSA",
+ "e": "AQAB",
+ "key_ops": ["verify"],
+ "alg": "PS512",
+ "n": "...Modulus des Public Key..."
+ }
},
"token_type": "sender"
}
```
-## Schritt 3: Zugriff auf die Antrags-API mittels Access Tokens
+## Schritt 3: Zugriff auf die Antrags-API mittels Proof-of-Possession-Token
+Für den Zugriff auf die Antrags-API des Zustelldienstes wird neben dem Access Token immer auch ein sog. Proof-of-Possession-Token in Anlehung an [Internet-Draft-OAuth-DPoP-03](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03) benötigt, der die generische [Zugriffsberechtigung des Onlinedienstes](./scopes.md) auf einen konkreten Zustellpunkt (Destination) und/oder einen konkreten Antragsvorgang einschränkt. Dies ermöglicht die Weitergabe von eingeschränkten Berechtigungstokens an das Endgerät der Antragsteller:in (Browser bzw. App) und einen direkten, eingeschränkten Zugriff des Endgeräts auf die Antrags-API.
-Für den Zugriff auf die Antrags-API des Zustelldienstes wird neben dem Onlineservice-Token immer auch ein sog. Access Token benötigt, der die generische [Zugriffsberechtigung des Onlinedienstes](./scopes.md) auf einen konkreten Zustellpunkt (Destination) und/oder einen konkreten Antragsvorgang einschränkt. Dies ermöglicht die Weitergabe von eingeschränkten Berechtigungstokens an das Endgerät der Antragsteller:in (Browser bzw. App) und einen direkten, eingeschränkten Zugriff des Endgeräts auf die Antrags-API.
+Jedes Onlineservice-Backend muss dazu in der Lage sein, Proof-of-Possession-Tokens für den Zugriff auf die Antrags-API zu erzeugen und an das Endgerät der Antragsteller:in (Browser/App) zu übermitteln. In den vom Online-Antragsdienst generierten Proof-of-Possession-Tokens DÜRFEN keine Informationen hinterlegt werden, die zur Identifizierung von Antragssteller:innen geeignet sind.
-Access Token und Onlineservice-Token müssen beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden. Mithilfe der beiden Tokens kann nachvollzogen werden, von welchem antragssendenden System ein Antrag an welchen Zustellpunkt übermittelt wird und ob das antragssendende System hierzu autorisiert ist.
+Access Token und Proof-of-Possession-Token müssen beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden. Mithilfe der beiden Tokens kann nachvollzogen werden, von welchem sendenden System ein Antrag an welchen Zustellpunkt übermittelt wird und ob das sendende System hierzu autorisiert ist. Der Access Token wird hierbei im `Authorization`-Header mit `Bearer`-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) übertragen; der Proof-of-Possession-Token im `DPoP`-Header gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 7.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-7.1):
**Beispiel**
-
```http
POST /applications HTTP/1.1
Host: api.zustelldienst-01.example.com
-token: XXX
-online-service-token: XXX
+Authorization: Bearer ey...
+DPoP: ey...
```
-Access Tokens werden entweder vom Online-Antragssservice mit Hilfe des bei der Registrierung erstellten Onlineservice-Schlüsselpaars oder vom Endgerät der Antragssteller:in mit Hilfe eines vorgangsspezifischen Schlüsselpaars signiert und DÜRFEN eine Gültigkeitsdauer von 2 Stunden NICHT überschreiten.
+Proof-of-Possession-Tokens werden entweder vom Online-Antragsservice mit Hilfe des bei der Registrierung erstellten Onlineservice-Schlüsselpaars oder vom Endgerät der Antragssteller:in mit Hilfe eines vorgangsspezifischen Schlüsselpaars signiert und DÜRFEN eine Gültigkeitsdauer von 2 Stunden NICHT überschreiten.
-Jedes Onlineservice-Backend muss dazu in der Lage sein, Access Tokens für den Zugriff auf die Antrags-API zu erzeugen und an das Endgerät der Antragsteller:in (Browser/App) zu übermitteln. Hierbei SOLLTE der Onlinedienst eine geeignete Form von Rate-Limiting für die Ausstellung der Access Tokens implementieren. Beim Zugriff auf die Antrags-API wird ein Rate-Limiting sowohl pro Online-Antragsdienst, als auch pro Antragsvorgang durchgeführt. In den vom Online-Antragsdienst generierten Access Tokens DÜRFEN keine Informationen hinterlegt werden, die zur Identifizierung von Antragssteller:innen geeignet sind.
+### Struktur des Proof-of-Possession-Tokens
+Im Folgenden wird der Aufbau der eingesetzten Proof-of-Possession-Tokens beschrieben. Die hier beschriebenen Implementierungsdetails sollen dem technischen Verständnis dienen und unterstützen bei der Implementierung von Software zur Generierung und Prüfung der Proof-of-Possession-Tokens. Die im Projekt FIT-Connect bereitgestellten Code-Beispiele und SDKs setzen die hier beschriebenen Vorgaben um und KÖNNEN genutzt werden, um die beschriebene Funktionalität einfach und sicher in sendenden Systemen zu implementieren.
-### Payload des Access Tokens
+#### Header des Proof-of-Possession-Tokens
+Alle generierten JWT-Tokens MÜSSEN den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2), über folgende Header-Attribute verfügen:
-Im Payload des signierten Access Tokens MÃœSSEN mindestens die folgenden [standartisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
+| Feld | Inhalt | **Erläuterung** |
+| ----- | ------------ | --------------- |
+| `typ` | `dpop+jwt` | Es handelt sich um einen Proof-of-Possession-Token. |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
+| `jwk` | *Public Key* | Repräsentation des Public Keys aus dem Schlüsselpaar, mit dem der Proof-of-Possession-Token signiert ist, im JWK-Format gemäß [RFC 7515, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.3). Hier MUSS entweder der *Public Key des Onlineservice* (aus dem Access Token) oder das *Schlüsselpaar des Antragsvorgangs* (siehe unten) hinterlegt sein. |
-| Feld | Inhalt | **Erläuterung** |
-| ---------------- | --------------------------- | --------------- |
-| `iat` | Unix Timestamp | Zeitpunkt, wann der Token ausgestellt wurde, als Unix Timestamp |
-| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
-| `iss` (Issuer) | ID des Onlineservice | Die ID des Onlineservice. Der angegebene Wert muss dem Feld `sub` des zugehörigen Onlineservice-Token entsprechen. |
-| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
-| `aud` (Audience) | *URL der Zustelldienst-API* | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
-| `scope` | Zustellberechtigungs-Scope | Eingeschränkte [Zustellberechtigung](./scopes.md) auf *eine* konkrete Destination-ID mit Präfix `destination:` (im Stile der Zustellberechtigungs-Scopes), für die der Token eine Antragseinreichung erlaubt. Der Zustellberechtigungs-Scope des zugehörigen Onlineservice-Token muss zur Antragseinreichung bei dieser Destination-ID berechtigen. |
-| `token_type` | *siehe unten* | Der Token-Typ gibt an, welche Funktion der ausgestellte Access Token erfüllt (siehe nächster Abschnitt). |
+**Beispiel-Header eines Proof-of-Possession-Token**
+```json
+{
+ "typ": "dpop+jwt",
+ "alg": "PS512",
+ "jwk": {
+ "kty": "RSA",
+ "e": "AQAB",
+ "key_ops": ["verify"],
+ "alg": "PS512",
+ "n": "...Modulus des Public Key..."
+ }
+}
+```
+#### Payload des Proof-of-Possession-Tokens
+Im Payload des signierten Proof-of-Possession-Tokens MÃœSSEN mindestens die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
-**Beispiel-Payload eines Access Token**
-
+| Feld | Inhalt | **Erläuterung** |
+| ---------------- | --------------------------- | --------------- |
+| `iat` | *Unix Timestamp* | Zeitpunkt, wann der Token ausgestellt wurde, als Unix Timestamp, gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2) |
+| `jti` | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens als UUID gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2). Für jeden Zugriff auf die API des Zustelldienstes muss eine unterschiedliche ID gewählt werden. |
+| `htm` | *HTTP-Methode des Requests* | Die HTTP-Methode (`GET`/`POST`/`PUT`/...) des beabsichtigten Zugriffs auf die API des Zustelldienstes gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2). |
+| `htu` | *URL des Requests* | Die URL des beabsichtigten Zugriffs auf die API des Zustelldienstes ohne Query (`?param=value`) und Fragment (`#hash`) gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2).
+| `ath` | *Hash des Access Token* | Base64Url-kodierter SHA-256-Hash der ASCII-Repräsentation des zugehörigen Access Token gemäß [Internet-Draft-OAuth-DPoP-03, Abschnitt 4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-4.2) |
+| `scope` | Zustellberechtigungs-Scope | Eingeschränkte [Zustellberechtigung](./scopes) auf *eine* konkrete Destination-ID mit Präfix `send:destination:` für die der Token eine Antragseinreichung erlaubt. Der Zustellberechtigungs-Scope des zugehörigen Access Token muss zur Antragseinreichung bei dieser Destination-ID berechtigen. |
+| `token_type` | *siehe unten* | Der Token-Typ gibt an, welche Funktion der ausgestellte Proof-of-Possession-Token erfüllt (siehe nächster Abschnitt). |
+
+**Beispiel-Payload eines Proof-of-Possession-Token**
```json
{
- "iat":"1620072619",
- "exp":"1620079819",
- "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "iat": "1620072619",
"jti": "b898ea5b-a411-4ba9-9b4c-64127e13c913",
- "aud": "api.zustelldienst-01.example.com",
- "scope": "destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
+ "htm": "POST",
+ "htu": "https://api.zustelldienst-01.example.com/submissions",
+ "ath": "UQWWOYDL96OdIi3cbhMUKFccQcHAXUOpO2U9bkIvSbc",
+ "scope": "send:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
"token_type": "create-submission"
}
```
-### Verwendung von Access Tokens
-
-Im Folgenden wird der Aufbau der eingesetzten Access Tokens beschrieben. Die hier beschriebenen Implementierungsdetails sollen dem technischen Verständnis dienen und unterstützen bei der Implementierung von Software zur Generierung und Prüfung der Access Tokens. Die im Projekt FIT-Connect bereitgestellten Code-Beispiele und SDKs setzen die hier beschriebenen Vorgaben um und KÖNNEN genutzt werden, um die beschriebene Funktionalität einfach und sicher in antragssendenden Systemen zu implementieren.
-
-Je nach Art des Zugriffs MÜSSEN unterschiedliche Vorgaben für Access Tokens eingehalten werden:
+### Zugriff auf die API des Zustelldienstes mittels Proof-of-Possession-Token
+#### Initiale Antragseinreichung / Vorgangseröffnung
+Je nach Art des Zugriffs MÜSSEN unterschiedliche Vorgaben für Proof-of-Possession-Tokens eingehalten werden:
-| Art des Zugriffs | Vorgaben für Access Token |
-| ---------------- | --------------------------|
-| Initiale Antragseinreichung inkl. Vorgangseröffnung | Der Access Token wird durch das Onlineservice-Schlüsselpaar signiert. Im Payload des Tokens wird der Token-Typ auf `token_type: "create-submission"` festgelegt. |
+| Art des Zugriffs | Vorgaben für Proof-of-Possession-Token |
+| ---------------- | -------------------------------------- |
+| Initiale Antragseinreichung inkl. Vorgangseröffnung | Der Proof-of-Possession-Token wird durch das Onlineservice-Schlüsselpaar signiert. Im Payload des Tokens wird der Token-Typ auf `token_type: "create-submission"` festgelegt. |
Dieser Token-Typ berechtigt ausschließlich zum Anlegen von neuen Antragsvorgängen.
-**Beispiel-Payload eines Access Token mit Token-Typ ```create-submission```**
+Onlineservices SOLLTEN bei der Ausstellung von Tokens zur Vorgangseröffnung eine geeignete Form von Rate-Limiting implementieren. Beim Zugriff auf die Antrags-API wird ein Rate-Limiting auf die Anzahl der eröffneten Einreichungen pro Online-Antragsdienst durchgeführt.
+**Beispiel-Payload eines Proof-of-Possession-Token mit Token-Typ ```create-submission```**
```json
{
- "iat":"1620072619",
- "exp":"1620079819",
- "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "iat": "1620072619",
"jti": "84573d90-ad99-419b-b696-79e058eeff6d",
- "aud": "api.zustelldienst-01.example.com",
- "scope": "destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
+ "htm": "POST",
+ "htu": "https://api.zustelldienst-01.example.com/submissions",
+ "ath": "UQWWOYDL96OdIi3cbhMUKFccQcHAXUOpO2U9bkIvSbc",
+ "scope": "send:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
"token_type": "create-submission"
}
```
-Beim Anlegen von neuen Antragsvorgängen MUSS für jeden Antragsvorgang ein separates kryptographisches Schlüsselpaar erzeugt werden (nachfolgend: Schlüsselpaar des Antragsvorgangs). Das Schlüsselpaar SOLLTE auf dem Endgerät der Antragsteller:in erzeugt werden. Sofern mit FIT-Connect eine Ende-zu-Ende-Verschlüsselung von der Antragsteller:in bis in das antragsempfangende System auf Verwaltungsseite realisiert werden soll, so MUSS das Schlüsselpaar auf dem Endgerät der Antragsteller:in erzeugt werden. Der öffentliche Schlüssel (Public Key) dieses Schlüsselpaares wird bei der Antragseinreichung über den Endpunkt `POST /applications` (TODO: Link) im eröffneten Vorgang hinterlegt.
-
-Anschließend ermöglicht das generierte Schlüsselpaar bzw. ein daraus generierter Access Token die Authentifizierung der Antragsteller\:in:
+Beim Anlegen von neuen Antragsvorgängen MUSS für jeden Antragsvorgang ein separates kryptographisches Schlüsselpaar erzeugt werden (nachfolgend: Schlüsselpaar des Antragsvorgangs). Das Schlüsselpaar SOLLTE auf dem Endgerät der Antragsteller:in erzeugt werden. Sofern mit FIT-Connect eine Ende-zu-Ende-Verschlüsselung von der Antragsteller:in bis in das empfangende System auf Verwaltungsseite realisiert werden soll, so MUSS das Schlüsselpaar auf dem Endgerät der Antragsteller:in erzeugt werden. Der öffentliche Schlüssel (Public Key) dieses Schlüsselpaares wird bei der Antragseinreichung über den Endpunkt `POST /submissions` (TODO: Link) im eröffneten Vorgang hinterlegt.
-| Art des Zugriffs | Vorgaben für Access Token |
-| ---------------- | --------------------------|
-| Uneingeschränkter Zugriff auf einen bestimmten Vorgang (Einreichen von Antragsdaten, Hinterlegen von Anhängen, Lesen und Schreiben des Event Log) | Der Access Token wird durch das Antragsvorgangs-Schlüsselpaar signiert. Ein Zugriff auf den Vorgang ist nur möglich, wenn im Zustelldienst zuvor der zugehörige Public Key des Antragsvorgangs-Schlüsselpaar hinterlegt wurde. Im Payload des Tokens wird der Token-Typ auf `token_type: access-case` festgelegt. |
+#### Zugriff auf eine Einreichung / einen Vorgang mittels Schlüsselpaar des Antragsvorgangs
+Anschließend ermöglicht das generierte Schlüsselpaar bzw. ein daraus generierter Proof-of-Possession-Token die Authentifizierung der Antragsteller\:in:
-Dieser Access Token wird mithilfe des Schlüsselpaares des Antragsvorgangs signiert. Im Zustelldienst wird die Signatur des Tokens mithilfe des bei der Antragserstellung hinterlegten Public Key geprüft. Der Access Token weist nach, dass der anfragende API-Client berechtigt ist, auf einen spezifischen Vorgang zuzugreifen. Mit Hilfe dieses Access Tokens können nun die Antragsdaten und Anhänge dem eröffneten Antrags hinzugefügt werden. Hierbei ist ein Zugriff auf die Antrags-API direkt durch das Endgerät der Antragsteller:in möglich.
+| Art des Zugriffs | Vorgaben für Proof-of-Possession-Token |
+| ---------------- | -------------------------------------- |
+| Uneingeschränkter Zugriff auf einen bestimmten Vorgang (Einreichen von Antragsdaten, Hinterlegen von Anhängen, Lesen und Schreiben des Event Log) | Der Proof-of-Possession-Token wird durch das Antragsvorgangs-Schlüsselpaar signiert. Ein Zugriff auf den Vorgang ist nur möglich, wenn im Zustelldienst zuvor der zugehörige Public Key des Antragsvorgangs-Schlüsselpaar hinterlegt wurde. Im Payload des Tokens wird der Token-Typ auf `token_type: access-case` festgelegt. |
-**Beispiel-Payload eines Access Token mit Token-Typ ```access-case```**
+Dieser Proof-of-Possession-Token wird mithilfe des Schlüsselpaares des Antragsvorgangs signiert. Im Zustelldienst wird die Signatur des Tokens mithilfe des bei der Antragserstellung hinterlegten Public Key geprüft. Der Proof-of-Possession-Token weist nach, dass der anfragende API-Client berechtigt ist, auf einen spezifischen Vorgang zuzugreifen. Mit Hilfe dieses Proof-of-Possession-Tokens können nun die Antragsdaten und Anhänge dem eröffneten Antrags hinzugefügt werden. Hierbei ist ein Zugriff auf die Antrags-API direkt durch das Endgerät der Antragsteller:in möglich.
+**Beispiel-Payload eines Proof-of-Possession-Token mit Token-Typ ```access-case```**
```json
{
- "iat":"1620072619",
- "exp":"1620079819",
- "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "iat": "1620072619",
"jti": "ba3ba9a1-19d3-446b-a504-af9250cbaecf",
- "aud": "api.zustelldienst-01.example.com",
- "scope": "destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
+ "htm": "POST",
+ "htu": "https://api.zustelldienst-01.example.com/submissions/afa3f4e6-27e3-40bb-99b7-33a30fd8c594",
+ "ath": "UQWWOYDL96OdIi3cbhMUKFccQcHAXUOpO2U9bkIvSbc",
+ "scope": "send:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
"token_type": "access-case"
}
```
-Der Onlinedienst hat nach wie vor - sofern er die Vorgangsreferenz des Vorganges (`caseId`) kennt - jederzeit lesenden und schreibenden Zugriff auf Statusbenachrichtigungen zu einem konkreten Vorgang im zugehörigen Event Log. Hierzu stellt sich der Onlineservice selbst ein Access Token aus und kann anschließend mit Access Token und Onlineservice-Token auf das Event Log zugreifen:
+#### Zugriff auf das Event Log eines Vorgangs durch den Onlineservice
+Der Onlinedienst hat nach wie vor - sofern er die Vorgangsreferenz des Vorganges (`caseId`) kennt - jederzeit lesenden und schreibenden Zugriff auf Statusbenachrichtigungen zu einem konkreten Vorgang im zugehörigen Event Log. Hierzu generiert der Onlineservice einen Proof-of-Possession-Token und kann anschließend mit Access Token und Proof-of-Possession-Token auf das Event Log zugreifen:
-| Art des Zugriffs | Vorgaben für Access Token |
-| ---------------- | --------------------------|
-| Lesen und Schreiben des Event Log | Der Access Token wird durch das Onlineservice-Schlüsselpaar signiert. Im Payload des Tokens wird der Token-Typ auf `token_type: "access-eventlog"` festgelegt. |
+| Art des Zugriffs | Vorgaben für Proof-of-Possession-Token |
+| ---------------- | -------------------------------------- |
+| Lesen und Schreiben des Event Log | Der Proof-of-Possession-Token wird durch das Onlineservice-Schlüsselpaar signiert. Im Payload des Tokens wird der Token-Typ auf `token_type: "access-eventlog"` festgelegt. |
-Mit Hilfe eines Access Tokens vom Typ `access-eventlog` können perspektivische auch andere berechtigte Systeme (z.B. Statusmonitor im Nutzer:innenkonto) auf den Status von Antragsvorgängen zugreifen).
-
-**Beispiel-Payload eines Access Token mit Token-Typ ```access-eventlog```**
+Mit Hilfe eines Proof-of-Possession-Tokens vom Typ `access-eventlog` können perspektivische auch andere berechtigte Systeme (z.B. Statusmonitor im Nutzer:innenkonto) auf den Status von Antragsvorgängen zugreifen).
+**Beispiel-Payload eines Proof-of-Possession-Token mit Token-Typ ```access-eventlog```**
```json
{
- "iat":"1620072619",
- "exp":"1620079819",
- "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "iat": "1620072619",
"jti": "2c633a19-9e84-4b23-8caf-960580e8c883",
- "aud": "api.zustelldienst-01.example.com",
- "scope": "destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
+ "htm": "GET",
+ "htu": "https://api.zustelldienst-01.example.com/cases/8a901de7-f592-473c-b9a8-7ed05d2a60f9/event-log",
+ "ath": "UQWWOYDL96OdIi3cbhMUKFccQcHAXUOpO2U9bkIvSbc",
+ "scope": "send:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
"token_type": "access-eventlog"
}
```
## Kryptographische Vorgaben
-
-### Kryptographische Vorgaben für JSON Web Tokens
-
-Alle generierten JWT-Tokens MÜSSEN den Vogaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
-
-| Feld | Inhalt | **Erläuterung** |
-| ----- | ------- | --------------- |
-| `typ` | `JWT` | Es handelt sich um einen JSON Web Token (JWT). |
-| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
-
-**Beispiel**
-```json
-{
- "typ":"JWT",
- "alg":"PS512"
-}
-```
-
-### Kryptographische Vorgaben für das im Onlineservice-Token hinterlegte Schlüsselpaar ("Onlineservice-Schlüsselpaar")
-Jedes antragssendende System MUSS vor der Registrierung im Self-Service-Portal ein Schlüsselpaar erzeugen und den öffentlichen Teil des Schüsselpaares (Public Key) bei der Registrierung im Self-Service angeben.
+### Kryptographische Vorgaben für das im Access Token hinterlegte Schlüsselpaar ("Onlineservice-Schlüsselpaar")
+Jedes sendende System MUSS vor der Registrierung im Self-Service-Portal ein Schlüsselpaar erzeugen und den öffentlichen Teil des Schüsselpaares (Public Key) bei der Registrierung im Self-Service angeben.
Das erzeugte Schlüsselpaar MUSS eine Schlüssellänge von 4096 Bit aufweisen. Der zugehörige Public Key im Format *JSON Web Key* (JWK) MUSS über die folgenden Attribute gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4) verfügen:
diff --git a/docs/details/authentication/subscriber.md b/docs/details/authentication/subscriber.md
index e4cc8a7ff3de6ce92ab5d3abbcb284dfdeeb67bd..7a34fc97639f151727266d23cdca188f45d16ea6 100644
--- a/docs/details/authentication/subscriber.md
+++ b/docs/details/authentication/subscriber.md
@@ -1,8 +1,8 @@
# Authentifizierung von empfangenden Systemen
-Die Authentifizierung von empfangenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Zum Abruf von Anträgen müssen sich empfangende Systeme mit Hilfe von OAuth 2.0 Client-Credentials beim Authorisierungsdienst authentifizieren. Die hierfür nötigen Client erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link)
+Die Authentifizierung von empfangenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Zum Abruf von Anträgen müssen sich empfangende Systeme mit Hilfe von OAuth 2.0 Client-Credentials beim Autorisierungsdienst authentifizieren. Die hierfür nötigen Client erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link)
-Zum Abruf von Anträgen müssen sich empfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server ein Berechtigungstoken (im Folgenden "Subscriber-Token") nach dem Standard JSON Web Token gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Subscriber-Token kann anschließend genutzt werden, um sich gegenüber der Antrags-API eines Zustelldienstes zu authentifizieren.
+Zum Abruf von Anträgen müssen sich empfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server ein Berechtigungstoken (im Folgenden "Access Token") nach dem Standard JSON Web Token gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Token kann anschließend genutzt werden, um sich gegenüber der Antrags-API eines Zustelldienstes zu authentifizieren.
Für jede Destination müssen folgende Informationen im Self-Service-Portal bereitgestellt werden
@@ -12,7 +12,7 @@ Entweder:
Oder:
-- Name und Bezeichung der angeboteten Leistungen, wenn diese nicht Teil des Leistungskataloges sind
+- Name und Bezeichnung der angebotenen Leistungen, wenn diese nicht Teil des Leistungskataloges sind
Außerdem
@@ -27,33 +27,46 @@ Bei erfolgreicher Registrierung erhält die für den Zustellpunkt verantwortlich
## Zugriff auf die Antrags-API mittels Access Token
-Der Access Token für empfangende Systeme muss beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden.
+Der Access Token für empfangende Systeme muss beim Zugriff auf die Antrags-API im `Authorization`-Header mit `Bearer`-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) an den Zustelldienst übermittelt:
**Beispiel**
-
```http
POST /applications HTTP/1.1
Host: api.zustelldienst-01.example.com
-Token: XXX
+Authorization: Bearer ey...
```
-### Payload des Access Tokens für empfangende Systeme
+### Header des Access Tokens für empfangende Systeme
+Im Header des Access Tokens für empfangende Systeme werden vom Autorisierungsdienst gemäß den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) die folgende Header-Attribute gesetzt:
+
+| Feld | Inhalt | **Erläuterung** |
+| ----- | ------- | --------------- |
+| `typ` | `JWT` | Es handelt sich um einen JSON Web Token (JWT). |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
+
+**Beispiel**
+```json
+{
+ "typ": "JWT",
+ "alg": "PS512"
+}
+```
-Im Payload des signierten Access Token MÃœSSEN mindestens die folgenden [standartisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
+### Payload des Access Tokens für empfangende Systeme
+Im Payload des signierten Access Token MÃœSSEN mindestens die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
| Feld | Inhalt | **Erläuterung** |
| --------------- | --------------------------------------- | --------------- |
-| `iat` | Unix Timestamp | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp |
-| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
-| `iss` (Issuer) | *URL des Authentifizierungsservers* | Die URL des Authentifizierungsservers, der das Token ausgestellt hat. |
-| `sub` (Subject) | ID des empfangenden Systems | Wird bei der Anmeldung des empfangenden Systems durch den Authorisierungsdienst festgelegt und dient zur Identifizierung des empfangenden Systems. |
+| `iat` | *Unix Timestamp* | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp |
+| `exp` | *Unix Timestamp* | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
+| `iss` (Issuer) | *URL des Autorisierungsservers* | Die URL des Autorisierungsservers, der das Token ausgestellt hat. |
+| `sub` (Subject) | *ID des empfangenden Systems* | Wird bei der Anmeldung des empfangenden Systems durch den Autorisierungsdienst festgelegt und dient zur Identifizierung des empfangenden Systems. |
| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
| `aud` (Audience) | *URL der Zustelldienst-API* | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
| `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der Zustellberechtigungs-Scopes, für die der Token einen Abruf von Anträgen erlaubt (Präfix `destination:subscribe`), separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) |
-| `token_type` | `subscriber` | Gibt an, das es sich um einen Token für ein empfangendes System handelt |
+| `token_type` | `subscriber` | Gibt an, das es sich um einen Token für ein empfangendes System handelt. |
**Beispiel-Payload eines Access Tokens mit Token-Typ `subscriber`**
-
```json
{
"iat": "1620072619",
@@ -61,37 +74,17 @@ Im Payload des signierten Access Token MÃœSSEN mindestens die folgenden [standar
"iss": "https://auth.fit-connect.example.com",
"sub": "7e336be5-7528-4832-a1da-756229b72ab3",
"jti": "f2456e4b-121e-4900-a1ad-a83f720d7e2d",
- "scope": "destination:subscribe:36141427-d405-40a4-8f8b-3592d544e85b destination:subscribe:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1",
+ "aud": "https://api.zustelldienst-01.example.com",
+ "scope": "subscribe:destination:36141427-d405-40a4-8f8b-3592d544e85b manage:destination:36141427-d405-40a4-8f8b-3592d544e85b",
"token_type": "subscriber"
}
```
-## Kryptographische Vorgaben
-
-### Kryptographische Vorgaben für JSON Web Tokens
-
-Alle generierten JWT-Tokens MÜSSEN den Vogaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
-
-| Feld | Inhalt | **Erläuterung** |
-| ----- | ------- | --------------- |
-| `typ` | `JWT` | Es handelt sich um einen JSON Web Token (JWT). |
-| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
-
-**Beispiel**
-
-```json
-{
- "typ": "JWT",
- "alg": "PS512"
-}
-```
-
## Validierung der JWT-Tokens durch den Zustelldienst
-
-Beim Abruf am Zustelldienst muss dieser bzw. das API-Gateway überprüfen, ob der JWT-Token valide ist. Dafür sollten mindestes folgende Überprüfungen durchgeführt werden:
+Beim Abruf am Zustelldienst muss dieser bzw. das API-Gateway überprüfen, ob der JWT-Token valide ist. Dafür sollten mindestens folgende Überprüfungen durchgeführt werden:
1. Überprüfen, ob es sich um einen JWT mit einer **RSASSA-PSS (PS512)** Signatur handelt.
2. Überprüfen, ob der JWT noch gültig ist.
3. Überprüfen, ob der JWT für max. 2h ausgestellt wurde.
-4. Mithilfe des Public Keys des Authentifizierungsservers überprüfen, ob die Signatur des JWT gültig ist.
+4. Mithilfe des Public Keys des Autorisierungsservers überprüfen, ob die Signatur des JWT gültig ist.
5. Überprüfen, ob die Destination-ID, die abgerufen werden soll, in den Zustellberechtigungs-Scopes des JWT enthalten ist (*scope* Parameter des JWT).
diff --git a/docs/details/encryption.mdx b/docs/details/encryption.mdx
index ba524549e0021fcf147b3067bc4bbaae3cf2202f..aa80e86091e0fbe086bb40964c052b928800ccb0 100644
--- a/docs/details/encryption.mdx
+++ b/docs/details/encryption.mdx
@@ -356,3 +356,11 @@ Die folgenden Attribute müssen im JOSE-Header bei der Übertragung signierter D
| alg | "PS512" | Legt RSASSA-PSS mit SHA512 als Algorithmus für die Signatur fest. Bezeichner gemäß [RFC 7518, Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) |
| kid | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "verify" aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verifizierung der Signatur dient. Gemäß [RFC7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4). |
| cty | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7515, Abschnitt 4.1.10](https://tools.ietf.org/html/rfc7515#section-4.1.10) |
+
+
+## Vorgaben für JSON Web Tokens (JWTs)
+Alle generierten JWT-Tokens MÜSSEN den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
+
+| Feld | Inhalt | **Erläuterung** |
+| ----- | ------- | --------------- |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |