Passa al contenuto principale

1. Introduzione (Introduction)

"Il Framework di Autorizzazione OAuth 2.0" [RFC6749] definisce il parametro scope che consente ai client OAuth di specificare lo scope richiesto, ovvero la capacità limitata, di un token di accesso. Questo meccanismo è sufficiente per implementare scenari statici e richieste di autorizzazione a grana grossa, come "dammi accesso in lettura al profilo del proprietario della risorsa". Tuttavia, non è sufficiente per specificare requisiti di autorizzazione a grana fine, come "per favore lasciami trasferire un importo di 45 Euro al Commerciante A" o "per favore dammi accesso in lettura alla directory A e accesso in scrittura al file X".

Questa specifica introduce un nuovo parametro authorization_details che consente ai client di specificare i loro requisiti di autorizzazione a grana fine utilizzando l'espressività delle strutture dati JSON [RFC8259].

Ad esempio, una richiesta di autorizzazione per un bonifico (designato come "iniziazione di pagamento" in diverse iniziative di open banking) può essere rappresentata utilizzando un oggetto JSON come questo:

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

Questo oggetto contiene informazioni dettagliate sul pagamento previsto, come importo, valuta e creditore, necessarie per informare l'utente e ottenere il suo consenso. Il server di autorizzazione (AS) e il rispettivo server di risorse (RS) (che fornisce l'API di iniziazione del pagamento) applicheranno insieme questo consenso.

Per una discussione completa delle sfide derivanti da nuovi casi d'uso negli spazi dell'open banking e della firma elettronica, vedere [Transaction-Auth].

Oltre a facilitare le richieste di autorizzazione personalizzate, questa specifica introduce anche un insieme di campi di tipi di dati comuni da utilizzare tra diverse API.

1.1. Convenzioni e Terminologia (Conventions and Terminology)​

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono tutte in maiuscolo, come mostrato qui.

Questa specifica utilizza i termini "token di accesso", "token di aggiornamento", "server di autorizzazione" (AS), "server di risorse" (RS), "endpoint di autorizzazione", "richiesta di autorizzazione", "risposta di autorizzazione", "endpoint del token", "tipo di concessione", "richiesta di token di accesso", "risposta di token di accesso" e "client" definiti da "Il Framework di Autorizzazione OAuth 2.0" [RFC6749].

Ultimo aggiornamento il