C_12804_Anlage - Änderungen an den Operationen zur Anbindung von Cloud-PS

ML-194102 - Änderungen an den Operationen zur Anbindung von Cloud-PS

[<=]

Inhaltsverzeichnis

1 Änderungsbeschreibung

2 Änderung in gemF_Personalisierung_HSM-B

2.1 4.2.1 Anforderungshaushalt

Am Ende des Absatz (vor 4.2.1.1) wir folgende AFO eingefügt

A_29680 - Umsetzung Autorisierung & Authentisierung nach OAuth2 und OIDC

Das Zugangsmodul MUSS für die Freigaben und Authentisierungen im Zuge von HSM-B-Personalisierung und Cloud-PS-Anbindung die geforderten Flows entsprechend OAuth nach [RFC6749] und OIDC nach [OpenID Connect Core] umsetzen und nur davon abweichen, sofern es per Anforderung gefordert ist.
[<=]

2.2 4.2.1.2 Nutzerauthentifizierung

AFO A_25119 wird angepasst

Alt:

A_25119 - Authentisierungs-Endpunkt - Löschen von Authorization-Codes

Das Zugangsmodul MUSS nach A_25106 erzeugte und versendete Authorization-Codes nach 10 min aus seinem Speicher löschen, darf diese also nach Ablauf dieser Zeit nicht mehr bei der Prüfung nach A_25102* akzeptieren. [<=]

Neu:

A_25119-01 - Authentisierungs-Endpunkt - Löschen von Authorization-Codes

Das Zugangsmodul MUSS nach A_25106* und A_28224* erzeugte und versendete Authorization-Codes nach deren Einlösung bzw. spätestens nach 10 min aus seinem Speicher löschen, darf diese also nur einmalig bzw. nach Ablauf dieser der genannten Zeit gar nicht mehr bei der Prüfung nach A_25102* akzeptieren. [<=]

2.3 4.2.1.3.1 Token-Endpunkt

AFO A_25119-01 wird angepasst

Alt:

A_25102-01 - SMB-Service - Operation getToken

Das Zugangsmodul MUSS in seinem SMB-Service die Operation getToken als Token-Endpunkt bereitstellen.
ServiceEndpunkt <SMB-Service-URL>/getToken
Eingangsparameter POST parameter:
  • grant_type = "authorization_code" und
  • code ist ein noch gültiger vom Authentisierungs-Endpunkt des Zugangsmodul erzeugter Authorization-Code.
Verarbeitung Das Zugangsmodul prüft auf grant_type ="authorization_code".
Das Zugangsmodul prüft, ob es zu diesem Code eine Nutzerauthentifizierung gespeichert hat, die noch nicht gelöscht wurde gemäß A_25119.
Das Zugangsmodul erstellt einen ID-Token wie in A_25108* (Anbieter SMC-B) oder A_26355 (Cloud-PS) beschrieben.
Response wie in A_25108*
Fehler
  • message: "Authorization-Code unbekannt oder abgelaufen", code: "SMBS_0002"
  • message: "grant_type ungültig", Code: "SMBS_0003"
  • message: "Interner Fehler bei der Token-Erzeugung", Code: "SMBS_0004"

[<=]

Neu:

A_25102-04 - SMB-Service - Operation getToken

Das Zugangsmodul MUSS in seinem SMB-Service die Operation getToken als Token-Endpunkt bereitstellen.

Tabelle 1 : Operation getToken des SMB-Service

ServiceEndpunkt <SMB-Service-URL>/getToken
Eingangsparameter POST parameter:
  • grant_type = "authorization_code" und
  • code ist ein noch gültiger vom Authentisierungs-Endpunkt des Zugangsmodul erzeugter Authorization-Code.
  • redirect_uri=<URL identisch wie in A_25086*>
  • client_id=<TSPName/Name aus TSL-Eintrag des Anbieters SMC-B>
Verarbeitung Das Zugangsmodul prüft auf grant_type ="authorization_code".
Das Zugangsmodul prüft, ob es zu diesem Code eine Nutzerauthentifizierung gespeichert hat, die noch nicht gelöscht wurde gemäß A_25119.
Das Zugangsmodul prüft die client_id gemäß A_25109*.
Das Zugangsmodul erstellt einen ID-Token wie in A_25108* (Anbieter SMC-B) oder bzw. einen ID-Token und Access-Token wie in A_26355* (Cloud-PS) beschrieben.
Response wie in A_25108* bzw. A_26355*
Fehler
  • message: "Authorization-Code unbekannt oder abgelaufen", code: "SMBS_0002"
  • message: "grant_type ungültig", Code: "SMBS_0003"
  • message: "Interner Fehler bei der Token-Erzeugung", Code: "SMBS_0004"

[<=]

AFO A_26355 wird angepasst

Alt:

A_26355 - Cloud-PS-Anbindung: Token-Endpunkt - Response im Erfolgsfall (Cloud-PS)

Das Zugangsmodul MUSS genau nur wenn die Prüfungen nach A_25102* erfolgreich waren:
den folgenden signierten ID-Token anhand der dem Authorization-Code zugeordneten Daten erzeugen:

     { "iss": "<URL entsprechend TSL-Eintrag nach A_25104>",
       "sub": "<GatewayUserID authentifizierter Nutzer>",
       "aud": "<Cloud-PS Name (client_id)>",
       "nonce": "<nonce aus Anfrage>",
       "exp": "<Ausstellungsdatum iat + 300 Sekunden>",
       "iat": "<aktuelle Zeit als Sekunden seit 1970-01-01T00:00:00Z in UTC>" }

den folgenden Access Token, wobei nur die angeforderten scope-Einträge zurückgemeldet werden:

{ "sub": "<GatewayUserID authentifizierter Nutzer>",
"iat": "aktuelle Zeit als Sekunden seit 1970-01-01T00:00:00Z in UTC",
"exp": "<Ausstellungsdatum iat + 300 Sekunden>",
"scope": "read:vKon use:vKon configure:vKon" }

 

Token Signatur:
JSON Web Signature (JWS) nach RFC7515 mit ECDSA mit P-256 und SHA-256 und entsprechendem Header:
     {"typ":"JWT",
      "alg":"ES256"}

diesen im weiteren als JWS in Compact Serialization verwenden:

BASE64(Header).BASE64(ID-Token).BASE64(Signature)

und dem Cloud-PS wie folgt antworten:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"<Acces-Token>",
  "token_type":"bearer",
  "expires_in":300,
  "id_token":<ID-Token in JWS Compact Serialization>,
}
[<=]

Neu:

A_26355-01 - Cloud-PS-Anbindung: Token-Endpunkt - Response im Erfolgsfall (Cloud-PS)

Das Zugangsmodul MUSS genau nur wenn die Prüfungen nach A_25102* erfolgreich waren:

den folgenden signierten ID-Token anhand der dem Authorization-Code zugeordneten Daten erzeugen:

     { "iss": "<URL entsprechend TSL-Eintrag nach A_25104>",
       "sub": "<GatewayUserID authentifizierter Nutzer>",
       "aud": "<Cloud-PS Name (client_id)>",
       "nonce": "<nonce aus Anfrage>",
       "exp": "<Ausstellungsdatum iat + 300 Sekunden>",
       "iat": "<aktuelle Zeit als Sekunden seit 1970-01-01T00:00:00Z in UTC>" }

den folgenden signierten Access-Token, wobei nur die angeforderten scope-Einträge zurückgemeldet werden:

{ "iss": "<URL entsprechend TSL-Eintrag nach A_25104>",
  "sub": "<GatewayUserID authentifizierter Nutzer>",
  "aud": "<Cloud-PS Name (client_id)>",
  "iat": "aktuelle Zeit als Sekunden seit 1970-01-01T00:00:00Z in UTC",
  "exp": "<Ausstellungsdatum iat + 300 Sekunden>",
  "scope": "read:vKon use:vKon configure:vKon" }

Token Signatur:

JSON Web Signature (JWS) nach [RFC7515] mit ECDSA mit P-256 und SHA-256 und entsprechendem Header:
     {"typ":"JWT",
      "alg":"ES256",
      "kid": <Referenz zum Öffentlichen Signaturschlüssel unter jwks_uri> }
(die Angabe der kid ist verpflichtend, wenn mehrere Schlüssel im jwks veröffentlicht werden)


diesen im weiteren als JWS in Compact Serialization verwenden:

BASE64(Header).BASE64(ID-Token).BASE64(Signature)

und dem Cloud-PS wie folgt antworten:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"<Access_Token>",
  "token_type":"bearer",
  "expires_in":300,
  "id_token":<ID-Token in JWS Compact Serialization>,
}
[<=]

2.4 4.2.1.3.4 Operationen zur Cloud-PS-Anbindung

AFO A_26356-01 wird angepasst

Alt:

A_26356-01 - Cloud-PS-Anbindung: Operation requestvKon

Das Zugangsmodul MUSS am SMB-Service die Operation requestvKon anbieten.
Service Endpunkt <SMB-Service-URL>/requestvKon
Eingangsparameter GET
Authorization: Bearer <ID-Token> <ACCESS_TOKEN>
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. extrahiere client_id aus sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe access_token auf scope read:vKon
  5. Rückmeldung an den Aufrufer
Rückgabe  Liste der HSK-Instanzen
{ vkon:
    [
         { name : "Name der HSK-Instanz" ;
            ip : "IP-Adresse der HSK-Instanz" }
    ]
}
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", message: "UserID in Token nicht gleich"
zu (3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10013", message: "Operation nicht authorisiert"
zu (5): Wenn keine HSK-Instanz ermittelt wird, ist das kein Fehler, sondern meldet eine leere Liste zurück: {vkon: [] }
sonst: code: "SMBS_10015", message: "Fehler in der Operation"

s [<=]

Neu:

A_26356-02 - Cloud-PS-Anbindung: Operation requestvKon

Das Zugangsmodul MUSS am SMB-Service die Operation requestvKon anbieten.

Tabelle 2 : Operation requestvKon des SMB-Service

Service Endpunkt <SMB-Service-URL>/requestvKon
Eingangsparameter GET
Authorization: Bearer <ID-Token> <Access_Token>
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Prüfe dass Systemzeit <= exp 
    Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. Extrahiere client_id aus aud sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe Access_Token auf scope read:vKon
  5. Rückmeldung an den Aufrufer
Rückgabe  Liste der virtuellen KonnektorHSK-Instanzen
{
    "vkon":  [
         {
            "id" : "ID der vInstanz",
            name : "Name der HSK- vInstanz",
            ip : "IP-Adresse der HSK- vInstanz"
          }
    ]
}
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", message: "Access Token abgelaufen UserID in Token nicht gleich"
zu (2): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (3): code: "SMBS_10013", message: "Operation nicht authorisiert"
zu (5): Wenn keine HSK-Instanz ermittelt wird, ist das kein Fehler, sondern meldet eine leere Liste zurück: {vkon: [] }
sonst: code: "SMBS_10015", message: "Fehler in der Operation"


[<=]

AFO A_28225-01 wird angepasst

Alt: 

A_28225-01 - Cloud-PS-Anbindung: Operation accessvKon

Das Zugangsmodul MUSS am SMB-Service die Operation accessvKon anbieten.

Service Endpunkt <SMB-Service-URL>/accessvKon
Eingangsparameter POST
Authorization: Bearer <ID_TOKEN> <ACCESS_TOKEN>

{ vkon :
     [
           { name : "Name der HSK-Instanz" ;
             ip: "IP-Adresse der HSK-Instanz" }
     ]
} 
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. extrahiere client_id aus sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe ob die übergebene(n) HSK-Instanz-IP(s) der GatewayUserID gehört.
  5. Wenn der Scope des access_tokens use:vKon enthält, schalte Firewall für Client_id zur den SOAP, LDAP, CETP und SICCT Interfaces des übergebenen HSK-Instanz-IP frei
  6. Wenn der Scope des access_tokens configure:vKon enthält, schalte Firewall für Client_id und für 60 min zum Admin Interfaces des übergebenen HSK-Instanz-IP frei
Rückgabe  code: "SMBS_1001", message: "Access granted"
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", message: "UserID in Token nicht gleich"
zu (3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10014", message: "vKon nicht authorisiert"
wenn der Scope weder use:vKon noch configure:vKon enthält: code: "SMBS_10013", message: "Operation nicht authorisiert"
sonst: code: "SMBS_10015", message: "Fehler in der Operation"

[<=]

Neu:

A_28225-02 - Cloud-PS-Anbindung: Operation accessvKon

Das Zugangsmodul MUSS am SMB-Service die Operation accessvKon anbieten.

Tabelle 3 : Operation accessvKon des SMB-Service

Service Endpunkt <SMB-Service-URL>/accessvKon
Eingangsparameter POST
Authorization: Bearer <ID_TOKEN> <Access_Token>

{
   vkon :  [
           {
             "id" : "vInstanz-ID"
             name : "Name der HSK-Instanz" ;
             ip: "IP-Adresse der HSK-Instanz"
           }
    ]
} 
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Prüfe dass Systemzeit <= exp
    Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. Extrahiere client_id aus aud sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe ob die übergebenen HSK- vInstanz-IDs IP(s) der GatewayUserID gehören
  5. Wenn der Scope des Access_Token use:vKon enthält, schalte Firewall für Client_id zur den SOAP, LDAP, CETP und SICCT Interfaces ders übergebenen HSK- vInstanz-IDs IP frei
  6. Wenn der Scope des Access_Token configure:vKon enthält, schalte Firewall für Client_id und für 60 min zum Admin Interfaces ders übergebenen HSK-vInstanz-IDs IP frei
Rückgabe  Wenn Vorgang erfolgreich abgeschlossen code: "SMBS_1001", message: "Access granted"
Wenn Vorgang noch in Bearbeitung code: "SMBS_1003", message: "Access pending"
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", "Access Token abgelaufen UserID in Token nicht gleich"
zu ( 3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10014", message: "vKon nicht authorisiert"
wenn der Scope weder use:vKon noch configure:vKon enthält: code: "SMBS_10013", message: "Operation nicht authorisiert"
sonst: code: "SMBS_10015", message: "Fehler in der Operation"

[<=]

AFO A_28226-01 wird angepasst

Alt:

A_28226-01 - Cloud-PS-Anbindung: Operation restrictvKon

Das Zugangsmodul MUSS am SMB-Service die Operation restrictvKon anbieten.

Service Endpunkt <SMB-Service-URL>/restrictvKon
Eingangsparameter POST
Authorization: Bearer <ID_TOKEN> <ACCESS_TOKEN>

{ vkon : 
    [
           { name : "Name der HSK-Instanz" ;
             ip: "IP-Adresse der HSK-Instanz" }
    ]
} 
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. extrahiere client_id aus sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe ob die übergebene(n) HSK-Instanz-IP(s) der GatewayUserID gehört.
  5. Sperre die Firewall für Client_id  zur übergebenen HSK-Instanz-IP. Wenn keine HSK-Instanz Liste übergeben wurde, sperre alle HSK-Instanzen dieser Client_Id
Rückgabe  code: "SMBS_1002", message: "Access withdrawn"
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", message: "UserID in Token nicht gleich"
zu (3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10014", message: "vKon nicht authorisiert"
sonst: code: "SMBS_10015", message: "Fehler in der Operation"

[<=]

Neu:

A_28226-02 - Cloud-PS-Anbindung: Operation restrictvKon

Das Zugangsmodul MUSS am SMB-Service die Operation restrictvKon anbieten.

Tabelle 4 : Operation restrictvKon des SMB-Service

Service Endpunkt <SMB-Service-URL>/restrictvKon
Eingangsparameter POST
Authorization: Bearer <ID_TOKEN> <Access_Token>

{
    "vkon" :  [
           {   
               "id" : "vInstanz-ID"
               name : "Name der HSK-Instanz" ;
               ip: "IP-Adresse der HSK-Instanz"
          }
   ]
} 
Verarbeitung
  1. Prüfe die Signatur von ID_Token und Access_Token
  2. Prüfe dass Systemzeit <= exp
    Extrahiere GatewayUserID aus access und ID Token. prüfe auf Identität
  3. Extrahiere client_id aus aud sub und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe Access_Token auf scope *:vKon
  5. Prüfe ob die übergebenen vInstanz-IDs HSK-Instanz-IP(s) der GatewayUserID gehören
  6. Sperre die Firewall für Client_id  zu den übergebenen vInstanz-IDs HSK-Instanz-IP. Wenn keine HSK-vInstanz-Liste übergeben wurde, sperre alle HSK-vInstanzen dieser Client_Id
Rückgabe  Wenn Vorgang erfolgreich abgeschlossen code: "SMBS_1002", message: "Access withdrawn"
Wenn Vorgang noch in Bearbeitung code: "SMBS_1004", message: "Restriction pending"
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignature ungültig"
zu (2): code: "SMBS_10011", message: "Access Token abgelaufen UserID in Token nicht gleich"
zu (3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10013", message: "Operation nicht autorisiert"
zu (45): code: "SMBS_10014", message: "vKon nicht authorisiert"
sonst: code: "SMBS_10015", message: "Fehler in der Operation"

[<=]

Neue Anforderung

A_29683 - Cloud-PS-Anbindung: Operation checkvKon

Das Zugangsmodul MUSS am SMB-Service die Operation checkvKon anbieten.

Tabelle 5 : Operation checkvKon der SMB Service

Service Endpunkt <SMB-Service-URL>/checkvKon
Eingangsparameter POST
Authorization: Bearer <Access_Token>
 
{
   "vkon" :   [
           {
              "id" : "vInstanz-ID"
           }
    ]
} 
Verarbeitung
  1. Prüfe die Signatur von Access_Token
  2. Prüfe dass Systemzeit <= exp + 3600 Sekunden
  3. Extrahiere client_id aus aud und prüfe ob konfiguriertes Cloud-PS
  4. Prüfe Access_Token auf scope *:vKon
  5. Prüfe ob die übergebenen vInstanz-IDs der GatewayUserID gehören
Rückgabe {
   "vkon" :   [
           {
              "id" : "vInstanz-ID",
              "grantedScopes" : [ "use:vKon", "configure:vKon" ]
           }
    ],
    "retrievedAt" : "datetime"
}

grantedScopes: aktueller Freischaltungsstatus der vInstanz
retrievedAt: Zeitpunkt der Statusbereitstellung
Fehlermeldung zu (1): code: "SMBS_10010", message: "Tokensignatur ungültig"
zu (2): code: "SMBS_10011", message: "Access Token abgelaufen"
zu (3): code: "SMBS_10012", message: "Cloud-PS unbekannt"
zu (4): code: "SMBS_10013", message: "Operation nicht autorisiert"
zu (5): code: "SMBS_10014", message: "vKon nicht autorisiert"
sonst: code: "SMBS_10015", message: "Fehler in der Operation"


[<=]

3 Änderung in gemILF_PS

Nach dem Einleitungsabsatz wird folgender Text eingefügt:

Im Folgenden werden virtuelle Konnektor-Instanzen die in den HSKs laufen als vInstanzen bezeichnet.

Neue AFO unter dem neu eingefügten Text / über A_26357

A_29679 - Umsetzung Autorisierung & Authentisierung nach OAuth2 und OIDC

Das Cloud-PS MUSS für die Freigabe des TI-GW-Nutzers zum Zugriff des Cloud-PS auf dessen vInstanz die geforderten Flows entsprechend OAuth nach [RFC6749] und OIDC nach [OpenID Connect Core] umsetzen und nur davon abweichen, sofern es im ILF per Anforderung gefordert ist.
[<=]

Die AFO A_28222 wird wie folgt angepasst und von gemF_Personalisierung_HSM-B nach gemILF_PS verschoben und dort unter A_29679 eingefügt.

Alt:

A_28222 - Redirect zur Authentifizierung am TI-Gateway (Cloud-PS)

Das Cloud-PS MUSS einen Auth-Request nach RFC 6749 mittels Redirect zum Cloud-PS Authentisierungs-Endpunkt des gewählten Anbieters TI-Gateway senden. Der Auth-Request muss folgendermaßen parametriert werden:
HTTP/1.1 302 Found
  Location: <URL Authentisierungs-Endpunkt entsprechend A_25116*>?
    response_type=code
    &scope=openid read:vKon use:vKon configure:vKon
    &client_id=<Cloud-PS Name wie zwischen Cloud-PS und TI-GW vereinbart>
    &state=<Random-String>
    &nonce=<individuelle 10 Minuten gültige Zufallszahl> 
    &redirect_uri=<Endpunkt zur Verarbeitung von Auth-Codes>
Das Cloud-PS muss für die späteren Auswertungen die Kombination von Anbieter TI-Gateway, state und nonce persistieren, wobei das Cloud-PS durchsetzen MUSS, dass jede nonce nur einmalig verwendet und nach 10 Minuten gelöscht wird.
Das Cloud-PS MUSS den scope read:vKon senden, um die HSK-Instanz des Nutzers abzurufen.
Das Cloud-PS MUSS den scope use:vKon senden, um eine HSK-Instanz zur Nutzung freizuschalten.
Das Cloud-PS MUSS den scope configure:vKon senden, um das Admin-Interface der HSK-Instanz freizuschalten. 
[<=]

Neu:

A_28222-01 - Redirect zur Authentifizierung am TI-Gateway (Cloud-PS)

Das Cloud-PS MUSS einen Auth-Request nach [RFC6749] mittels Redirect zum Cloud-PS Authentisierungs-Endpunkt des gewählten Anbieters TI-Gateway senden. Der Auth-Request muss folgendermaßen parametriert werden:
HTTP/1.1 302 Found
  Location: <URL Authentisierungs-Endpunkt entsprechend A_25116*>?
    response_type=code
    &scope=openid read:vKon use:vKon configure:vKon
    &client_id=<Cloud-PS Name wie zwischen Cloud-PS und TI-GW vereinbart>
    &state=<individuelle 10 Minuten gültige Zufallszahl != nonce>
    &nonce=<individuelle 10 Minuten gültige Zufallszahl != state> 
    &redirect_uri=<Endpunkt zur Verarbeitung von Authorization Codes>
Das Cloud-PS muss für die späteren Auswertungen die Kombination von Cloud-PS-Nutzer-Session, Anbieter TI-Gateway, state und nonce persistieren, wobei das Cloud-PS durchsetzen MUSS, dass jede nonce und state nur einmalig verwendet und nach 10 Minuten gelöscht wird.
Das Cloud-PS MUSS den scope read:vKon senden, um die vInstanzen des Nutzers abzurufen.
Das Cloud-PS MUSS den scope use:vKon senden, um vInstanzen zur Nutzung freizuschalten.
Das Cloud-PS MUSS den scope configure:vKon senden, um das Admin-Interface von vInstanzen freizuschalten. 
 
[<=]

Hinweis unter A_28222-01

Hinweis: Um mit einem Access Token später mehrere Aktionen für einen Nutzer durchführen zu können (bspw. Informationen zur vInstanz abrufen und vom Nutzer gewünschte Freischaltungen am TI-Gateway durchführen), müssen alle benötigten Scopes in einem Auth-Request angegeben werden. Werden separate Auth-Requests verwendet, muss der Nutzer mehrfach die Authentifizierung beim TI-Gateway Anbieter durchlaufen.

Neue AFO unter A_28222-01

A_29681 - Verarbeitung Authorization Code durch Cloud-PS

Das Cloud-PS MUSS unter der redirect_uri (vgl. A_28222*) empfangene Requests hinsichtlich des Parameters state prüfen, ob dieser für die aktuelle PS-Nutzer-Session valide ist und nur im Erfolgsfall:

[<=]

Neue AFO unter A_29681

A_29682 - Auswertung ID-Token und Access-Token durch Cloud-PS

Das Cloud-PS MUSS einen mittels getToken vom TI-Gateway empfangenen ID-Token und Access-Token wie folgt auswerten:


[<=]

Ergänzung bei Referenzierte Dokumente

3.1.1 8.6.2 Weitere Dokumente

[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[OpenID Connect Core]

OpenID Connect Core 1.0 (incorporating errata set 2, 15, December 2023)
https://openid.net/specs/openid-connect-core-1_0.html  
[RFC6749] The OAuth 2.0 Authorization Framework (October 2012) https://datatracker.ietf.org/doc/html/rfc6749