1. Introduction

"The OAuth 2.0 Authorization Framework" [RFC6749] defines the scope parameter that allows OAuth clients to specify the requested scope, i.e., the limited capability, of an access token. This mechanism is sufficient to implement static scenarios and coarse-grained authorization requests, such as "give me read access to the resource owner's profile." However, it is not sufficient to specify fine-grained authorization requirements, such as "please let me transfer an amount of 45 Euros to Merchant A" or "please give me read access to directory A and write access to file X."

This specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON [RFC8259] data structures.

For example, an authorization request for a credit transfer (designated as "payment initiation" in several open banking initiatives) can be represented using a JSON object like this:

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

This object contains detailed information about the intended payment, such as amount, currency, and creditor, that is required to inform the user and obtain their consent. The authorization server (AS) and the respective resource server (RS) (providing the payment initiation API) will together enforce this consent.

For a comprehensive discussion of the challenges arising from new use cases in the open banking and electronic signing spaces, see [Transaction-Auth].

In addition to facilitating custom authorization requests, this specification also introduces a set of common data type fields for use across different APIs.

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This specification uses the terms "access token", "refresh token", "authorization server" (AS), "resource server" (RS), "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by "The OAuth 2.0 Authorization Framework" [RFC6749].

1.1. Conventions and Terminology​

1.1. Conventions and Terminology