Appendice A. Esempi Aggiuntivi (Additional Examples)
A.1. OpenID Connect
OpenID Connect [OpenID.Core] definisce un parametro claims per richiedere rivendicazioni di identità sull'utente finale. Questo parametro può essere utilizzato in una richiesta di autorizzazione come definito nella Sezione 5.5 di [OpenID.Core] o in un oggetto di richiesta come definito nella Sezione 6.1 di [OpenID.Core].
Con RAR, il client può alternativamente utilizzare un oggetto di dettagli di autorizzazione di tipo openid_credential per richiedere l'emissione di un ID Token OpenID Connect con rivendicazioni specifiche. L'esempio seguente mostra come il client può richiedere l'emissione di un ID Token che include le rivendicazioni email e email_verified:
[
{
"type": "openid_credential",
"credential_type": "id_token",
"locations": ["https://example.com"],
"claims": {
"email": null,
"email_verified": null
}
}
]
L'oggetto di dettagli di autorizzazione di tipo openid_credential con un credential_type di id_token PUÒ contenere i seguenti elementi:
- type: RICHIESTO (REQUIRED). Stringa che determina il tipo di dettagli di autorizzazione. Per l'emissione di un ID Token OpenID Connect, questo valore DEVE essere
openid_credential. - credential_type: RICHIESTO (REQUIRED). Stringa che determina il tipo di credenziale da emettere. Per un ID Token OpenID Connect, questo DEVE essere
id_token. - locations: OPZIONALE (OPTIONAL). Array di stringhe, ciascuna rappresentante un URI di un server di risorse dove la credenziale sarà utilizzata.
- claims: OPZIONALE (OPTIONAL). Un oggetto che descrive le rivendicazioni da incorporare nella credenziale. Il valore è un oggetto JSON con i nomi delle rivendicazioni richieste come nomi di membri e null o un oggetto JSON come valori di membri per esprimere requisiti di rivendicazione specifici.
A.2. Autorizzazione Specifica della Transazione (Transaction-Specific Authorization)
Questo esempio illustra come RAR può essere utilizzato per esprimere l'autorizzazione per una transazione di pagamento. L'esempio presuppone un bonifico tra conti.
Il valore type utilizzato è payment_initiation, che è l'identificatore di un tipo di dettagli di autorizzazione (fittizio) per l'iniziazione del pagamento.
Una richiesta di autorizzazione di esempio potrebbe essere così:
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
Il parametro authorization_details, decodificato URL per una migliore leggibilità, contiene il seguente documento JSON:
[
{
"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'oggetto di dettagli di autorizzazione per l'iniziazione del pagamento contiene i seguenti elementi:
- type: RICHIESTO (REQUIRED). Il tipo di dettagli di autorizzazione, che è
payment_initiationper questo esempio. - actions: OPZIONALE (OPTIONAL). Array di stringhe, rappresentanti le azioni per cui il client sta richiedendo l'autorizzazione di eseguire. In questo esempio,
initiatesignifica creare un nuovo pagamento,statussignifica leggere lo stato di un pagamento ecancelsignifica annullare un pagamento. - locations: OPZIONALE (OPTIONAL). Array di stringhe che rappresentano le posizioni dove il client intende spendere il token di accesso.
- instructedAmount: RICHIESTO (REQUIRED). Oggetto con due elementi,
currencyeamount, che rappresentano l'importo da trasferire. - creditorName: RICHIESTO (REQUIRED). Stringa che rappresenta il nome del commerciante.
- creditorAccount: RICHIESTO (REQUIRED). Oggetto contenente il numero di conto del commerciante. In questo esempio, il conto è rappresentato come un IBAN (International Bank Account Number), ma sono possibili altre rappresentazioni.
- remittanceInformationUnstructured: OPZIONALE (OPTIONAL). Stringa che rappresenta le informazioni di rimessa per il pagamento.
A.3. Token di Accesso Multipli (Multiple Access Tokens)
Questo esempio illustra come un client può richiedere l'autorizzazione per avere due token di accesso diversi emessi, uno da utilizzare sulla risorsa payment_api e un altro da utilizzare sulla risorsa 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"
}
]
}
]
In questo esempio, il client richiede l'autorizzazione per due oggetti di dettagli di autorizzazione diversi:
- Un'autorizzazione
payment_initiationda utilizzare suhttps://example.com/payment_api - Un'autorizzazione
account_informationda utilizzare suhttps://example.com/account_api
Se l'AS decide di emettere token di accesso separati per ogni risorsa, il client può effettuare due richieste di token separate:
Richiesta di Token 1 (per 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
Richiesta di Token 2 (per 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. Dettagli di Autorizzazione Arricchiti nella Risposta del Token (Enriched Authorization Details in Token Response)
Questo esempio mostra un oggetto di dettagli di autorizzazione di tipo payment_initiation che è stato arricchito dall'AS nella risposta del token con dati aggiuntivi come la date dell'autorizzazione:
{
"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"
}
Il campo date è stato aggiunto dall'AS per indicare quando l'autorizzazione è stata concessa.