Zum Hauptinhalt springen

Anhang A. Zusätzliche Beispiele (Additional Examples)

A.1. OpenID Connect​

OpenID Connect [OpenID.Core] definiert einen claims-Parameter, um Identitätsansprüche über den Endbenutzer anzufordern. Dieser Parameter kann in einer Autorisierungsanfrage wie in Abschnitt 5.5 von [OpenID.Core] definiert oder in einem Request-Objekt wie in Abschnitt 6.1 von [OpenID.Core] definiert verwendet werden.

Mit RAR kann der Client alternativ ein Autorisierungsdetail-Objekt vom Typ openid_credential verwenden, um die Ausstellung eines OpenID Connect ID Token mit spezifischen Claims anzufordern. Das folgende Beispiel zeigt, wie der Client die Ausstellung eines ID Token anfordern kann, das die Claims email und email_verified enthält:

[
   {
      "type": "openid_credential",
      "credential_type": "id_token",
      "locations": ["https://example.com"],
      "claims": {
         "email": null,
         "email_verified": null
      }
   }
]

Das Autorisierungsdetail-Objekt vom Typ openid_credential mit einem credential_type von id_token KANN die folgenden Elemente enthalten:

  • type: ERFORDERLICH (REQUIRED). String, der den Autorisierungsdetail-Typ bestimmt. Für die Ausstellung eines OpenID Connect ID Token MUSS dieser Wert openid_credential sein.
  • credential_type: ERFORDERLICH (REQUIRED). String, der den Typ des auszustellenden Credentials bestimmt. Für ein OpenID Connect ID Token MUSS dies id_token sein.
  • locations: OPTIONAL (OPTIONAL). Array von Strings, die jeweils einen URI eines Ressourcenservers darstellen, wo das Credential verwendet wird.
  • claims: OPTIONAL (OPTIONAL). Ein Objekt, das die in das Credential einzubettenden Claims beschreibt. Der Wert ist ein JSON-Objekt mit den Namen der angeforderten Claims als Mitgliedsnamen und null oder einem JSON-Objekt als Mitgliedswerten, um spezifische Claim-Anforderungen auszudrücken.

A.2. Transaktionsspezifische Autorisierung (Transaction-Specific Authorization)​

Dieses Beispiel veranschaulicht, wie RAR verwendet werden kann, um die Autorisierung für eine Zahlungstransaktion auszudrücken. Das Beispiel geht von einer Kreditübertragung zwischen Konten aus.

Der verwendete type-Wert ist payment_initiation, der Identifikator eines (fiktiven) Autorisierungsdetail-Typs für die Zahlungsinitiierung.

Eine Beispiel-Autorisierungsanfrage könnte so aussehen:

GET /authorize?response_type=code
   &client_id=s6BhdRkqt3
   &state=af0ifjsldkj
   &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
   &code_challenge_method=S256
   &authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%0A%20%20%20%20%20%20%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5D%2C%0A%20%20%20%20%20%20%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fpayments%22%5D%2C%0A%20%20%20%20%20%20%22instructedAmount%22%3A%7B%0A%20%20%20%20%20%20%20%20%20%22currency%22%3A%22EUR%22%2C%0A%20%20%20%20%20%20%20%20%20%22amount%22%3A%22123%2E50%22%0A%20%20%20%20%20%20%7D%2C%0A%20%20%20%20%20%20%22creditorName%22%3A%22Merchant%20A%22%2C%0A%20%20%20%20%20%20%22creditorAccount%22%3A%7B%0A%20%20%20%20%20%20%20%20%20%22iban%22%3A%22DE02100100109307118603%22%0A%20%20%20%20%20%20%7D%2C%0A%20%20%20%20%20%20%22remittanceInformationUnstructured%22%3A%22Ref%20Number%20Merchant%22%0A%20%20%20%7D%5D HTTP/1.1
Host: as.example.com

Der authorization_details-Parameter, URL-dekodiert für bessere Lesbarkeit, enthält das folgende JSON-Dokument:

[
   {
      "type": "payment_initiation",
      "actions": ["initiate", "status", "cancel"],
      "locations": ["https://example.com/payments"],
      "instructedAmount": {
         "currency": "EUR",
         "amount": "123.50"
      },
      "creditorName": "Merchant A",
      "creditorAccount": {
         "iban": "DE02100100109307118603"
      },
      "remittanceInformationUnstructured": "Ref Number Merchant"
   }
]

Das Autorisierungsdetail-Objekt für die Zahlungsinitiierung enthält die folgenden Elemente:

  • type: ERFORDERLICH (REQUIRED). Der Typ der Autorisierungsdetails, der für dieses Beispiel payment_initiation ist.
  • actions: OPTIONAL (OPTIONAL). Array von Strings, die die Aktionen darstellen, für die der Client eine Autorisierung anfordert. In diesem Beispiel bedeutet initiate das Erstellen einer neuen Zahlung, status das Lesen des Status einer Zahlung und cancel das Stornieren einer Zahlung.
  • locations: OPTIONAL (OPTIONAL). Array von Strings, die die Orte darstellen, an denen der Client das Zugriffstoken ausgeben möchte.
  • instructedAmount: ERFORDERLICH (REQUIRED). Objekt mit zwei Elementen, currency und amount, die den zu überweisenden Betrag darstellen.
  • creditorName: ERFORDERLICH (REQUIRED). String, der den Namen des Händlers darstellt.
  • creditorAccount: ERFORDERLICH (REQUIRED). Objekt, das die Kontonummer des Händlers enthält. In diesem Beispiel wird das Konto als IBAN (International Bank Account Number) dargestellt, aber andere Darstellungen sind möglich.
  • remittanceInformationUnstructured: OPTIONAL (OPTIONAL). String, der die Überweisungsinformationen für die Zahlung darstellt.

A.3. Mehrere Zugriffstoken (Multiple Access Tokens)​

Dieses Beispiel veranschaulicht, wie ein Client eine Autorisierung anfordern kann, um zwei verschiedene Zugriffstoken ausgestellt zu bekommen, eines zur Verwendung bei der payment_api-Ressource und ein anderes zur Verwendung bei der account_api-Ressource.

[
   {
      "type": "payment_initiation",
      "locations": ["https://example.com/payment_api"],
      "instructedAmount": {
         "currency": "EUR",
         "amount": "123.50"
      },
      "creditorName": "Merchant A",
      "creditorAccount": {
         "iban": "DE02100100103307118603"
      }
   },
   {
      "type": "account_information",
      "locations": ["https://example.com/account_api"],
      "accounts": [
         {
            "iban": "DE40100100103307118608"
         },
         {
            "iban": "DE40100100103307118888"
         }
      ]
   }
]

In diesem Beispiel fordert der Client eine Autorisierung für zwei verschiedene Autorisierungsdetail-Objekte an:

  1. Eine payment_initiation-Autorisierung zur Verwendung bei https://example.com/payment_api
  2. Eine account_information-Autorisierung zur Verwendung bei https://example.com/account_api

Wenn der AS beschließt, separate Zugriffstoken für jede Ressource auszustellen, kann der Client zwei separate Token-Anfragen stellen:

Token-Anfrage 1 (für payment_api):

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=3641c0461d016ba09c5796b3e7cc5...
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpayment_api%22%5D%7D%5D

Token-Anfrage 2 (für account_api):

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=3641c0461d016ba09c5796b3e7cc5...
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&authorization_details=%5B%7B%22type%22%3A%22account_information%22%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Faccount_api%22%5D%7D%5D

A.4. Angereicherte Autorisierungsdetails in der Token-Antwort (Enriched Authorization Details in Token Response)​

Dieses Beispiel zeigt ein Autorisierungsdetail-Objekt vom Typ payment_initiation, das vom AS in der Token-Antwort mit zusätzlichen Daten wie dem date der Autorisierung angereichert wurde:

{
   "type": "payment_initiation",
   "actions": ["initiate", "status", "cancel"],
   "locations": ["https://example.com/payments"],
   "instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant",
   "date": "2021-08-12"
}

Das date-Feld wurde vom AS hinzugefügt, um anzugeben, wann die Autorisierung erteilt wurde.

Letztes Update am