1. Introduction

"Le Cadre d'Autorisation OAuth 2.0" [RFC6749] définit le paramètre scope qui permet aux clients OAuth de spécifier le scope demandé, c'est-à-dire la capacité limitée, d'un jeton d'accès. Ce mécanisme est suffisant pour implémenter des scénarios statiques et des demandes d'autorisation à grain grossier, telles que "donnez-moi un accès en lecture au profil du propriétaire de la ressource". Cependant, il n'est pas suffisant pour spécifier des exigences d'autorisation à grain fin, telles que "veuillez me laisser transférer un montant de 45 euros au commerçant A" ou "veuillez me donner un accès en lecture au répertoire A et un accès en écriture au fichier X".

Cette spécification introduit un nouveau paramètre authorization_details qui permet aux clients de spécifier leurs exigences d'autorisation à grain fin en utilisant l'expressivité des structures de données JSON [RFC8259].

Par exemple, une demande d'autorisation pour un virement bancaire (désigné comme "initiation de paiement" dans plusieurs initiatives de banque ouverte) peut être représentée à l'aide d'un objet JSON comme celui-ci:

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

Cet objet contient des informations détaillées sur le paiement prévu, telles que le montant, la devise et le créancier, qui sont nécessaires pour informer l'utilisateur et obtenir son consentement. Le serveur d'autorisation (AS) et le serveur de ressources respectif (RS) (fournissant l'API d'initiation de paiement) appliqueront conjointement ce consentement.

Pour une discussion complète des défis découlant de nouveaux cas d'usage dans les domaines de la banque ouverte et de la signature électronique, voir [Transaction-Auth].

En plus de faciliter les demandes d'autorisation personnalisées, cette spécification introduit également un ensemble de champs de types de données communs à utiliser dans différentes API.

1.1. Conventions et Terminologie (Conventions and Terminology)

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Cette spécification utilise les termes "jeton d'accès", "jeton de rafraîchissement", "serveur d'autorisation" (AS), "serveur de ressources" (RS), "point de terminaison d'autorisation", "demande d'autorisation", "réponse d'autorisation", "point de terminaison de jeton", "type d'octroi", "demande de jeton d'accès", "réponse de jeton d'accès" et "client" définis par "Le Cadre d'Autorisation OAuth 2.0" [RFC6749].

1.1. Conventions et Terminologie (Conventions and Terminology)​

1.1. Conventions et Terminologie (Conventions and Terminology)