Aller au contenu principal

Annexe A. Exemples Supplémentaires (Additional Examples)

A.1. OpenID Connect​

OpenID Connect [OpenID.Core] définit un paramètre claims pour demander des revendications d'identité concernant l'utilisateur final. Ce paramètre peut être utilisé dans une demande d'autorisation comme défini dans la Section 5.5 de [OpenID.Core] ou dans un objet de demande comme défini dans la Section 6.1 de [OpenID.Core].

Avec RAR, le client peut alternativement utiliser un objet de détails d'autorisation de type openid_credential pour demander l'émission d'un ID Token OpenID Connect avec des revendications spécifiques. L'exemple suivant montre comment le client peut demander l'émission d'un ID Token qui inclut les revendications email et email_verified:

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

L'objet de détails d'autorisation de type openid_credential avec un credential_type de id_token PEUT contenir les éléments suivants:

  • type: REQUIS (REQUIRED). Chaîne qui détermine le type de détails d'autorisation. Pour l'émission d'un ID Token OpenID Connect, cette valeur DOIT être openid_credential.
  • credential_type: REQUIS (REQUIRED). Chaîne qui détermine le type de credential à émettre. Pour un ID Token OpenID Connect, cela DOIT être id_token.
  • locations: OPTIONNEL (OPTIONAL). Tableau de chaînes, chacune représentant un URI d'un serveur de ressources où le credential sera utilisé.
  • claims: OPTIONNEL (OPTIONAL). Un objet décrivant les revendications à intégrer dans le credential. La valeur est un objet JSON avec les noms des revendications demandées comme noms de membres et null ou un objet JSON comme valeurs de membres pour exprimer des exigences de revendication spécifiques.

A.2. Autorisation Spécifique à la Transaction (Transaction-Specific Authorization)​

Cet exemple illustre comment RAR peut être utilisé pour exprimer l'autorisation pour une transaction de paiement. L'exemple suppose un virement de crédit entre comptes.

La valeur type utilisée est payment_initiation, qui est l'identifiant d'un type de détails d'autorisation (fictif) pour l'initiation de paiement.

Un exemple de demande d'autorisation pourrait ressembler à ceci:

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

Le paramètre authorization_details, décodé URL pour une meilleure lisibilité, contient le document JSON suivant:

[
   {
      "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"
   }
]

L'objet de détails d'autorisation pour l'initiation de paiement contient les éléments suivants:

  • type: REQUIS (REQUIRED). Le type de détails d'autorisation, qui est payment_initiation pour cet exemple.
  • actions: OPTIONNEL (OPTIONAL). Tableau de chaînes, représentant les actions pour lesquelles le client demande l'autorisation d'effectuer. Dans cet exemple, initiate signifie créer un nouveau paiement, status signifie lire le statut d'un paiement, et cancel signifie annuler un paiement.
  • locations: OPTIONNEL (OPTIONAL). Tableau de chaînes représentant les emplacements où le client a l'intention de dépenser le jeton d'accès.
  • instructedAmount: REQUIS (REQUIRED). Objet avec deux éléments, currency et amount, représentant le montant à transférer.
  • creditorName: REQUIS (REQUIRED). Chaîne représentant le nom du marchand.
  • creditorAccount: REQUIS (REQUIRED). Objet contenant le numéro de compte du marchand. Dans cet exemple, le compte est représenté comme un IBAN (International Bank Account Number), mais d'autres représentations sont possibles.
  • remittanceInformationUnstructured: OPTIONNEL (OPTIONAL). Chaîne représentant les informations de remise pour le paiement.

A.3. Jetons d'Accès Multiples (Multiple Access Tokens)​

Cet exemple illustre comment un client peut demander l'autorisation d'avoir deux jetons d'accès différents émis, un à utiliser sur la ressource payment_api et un autre à utiliser sur la ressource account_api.

[
   {
      "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"
         }
      ]
   }
]

Dans cet exemple, le client demande l'autorisation pour deux objets de détails d'autorisation différents:

  1. Une autorisation payment_initiation à utiliser sur https://example.com/payment_api
  2. Une autorisation account_information à utiliser sur https://example.com/account_api

Si l'AS décide d'émettre des jetons d'accès séparés pour chaque ressource, le client peut faire deux demandes de jeton séparées:

Demande de Jeton 1 (pour 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

Demande de Jeton 2 (pour 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. Détails d'Autorisation Enrichis dans la Réponse de Jeton (Enriched Authorization Details in Token Response)​

Cet exemple montre un objet de détails d'autorisation de type payment_initiation qui a été enrichi par l'AS dans la réponse de jeton avec des données supplémentaires telles que la date de l'autorisation:

{
   "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"
}

Le champ date a été ajouté par l'AS pour indiquer quand l'autorisation a été accordée.

Dernière mise à jour le