ID d'intention Open Banking du mappage de la demande OpenID Connect
Lorsqu'une application tierce souhaite lancer une transaction nécessitant une autorisation de l'utilisateur (par exemple, transfert de paiement), elle utilise une API fournie par l'institution financière ou la banque pour enregistrer les détails de la transaction. Par exemple, elle enregistre le montant de la transaction et le type de devise. Ce processus est parfois appelé « dépôt d'une intention ». L'API répond avec un identificateur de tentative, également appelé ID de consentement dans les spécifications UK Open Banking. L'application lance un flux de code d'autorisation OAuth pour obtenir l'autorisation de l'utilisateur qui est enregistrée en tant que consentement de l'utilisateur.
- Extrayez l'ID de l'intention de la demande.
- Obtenez les informations de contexte d'intention, généralement en appelant l'API de la banque.
- Choisissez comment représenter l'autorisation dans
id_tokencomme valeur de demande ou de portée.
Objets d'entrée disponibles
Étant donné que cette règle personnalisée est exécutée après l'authentification mais avant l'autorisation, les informations disponibles ne comprennent pas tous les objets de domaine possibles. Ils sont limités aux types suivants.
- Contexte de demande HTTP
- Lorsqu'un utilisateur se connecte à Verify, le contexte de requête HTTP entrant est accessible dans la règle de mappage des demandes. Tous les paramètres de requête OAuth, tels que
claimsetscope, sont disponibles dans cetterequestContext. La structure générale et l'utilisation derequestContextsont décrites dans la section « Contexte HTTP de requête » des fonctions d'attribut.Pour simplifier l'accès, certaines valeurs sont précalculées dansrequestContext. Le paramètre de requêteclaimsest généralement représenté comme un JSON comme l'exemple suivant.{ "id_token": { "claim_name": { "essential": false, "value": "some_value" } }, "userinfo": { "claim_name": { "essential": false, "value": "some_value" } } }Cet élément JSON peut être difficile d'accès et la clé utilisée dans le fichier
requestContextest donc au formatclaims_claimType_claimName.claimTypeestuserinfoouidtoken. Notez le trait de soulignement manquant. Ainsi, avec l'exemple précédent, la valeurclaim_namepeut être obtenue à l'aide derequestContext.getValue('claims_idtoken_claim_name').De même,
scopeest calculé et divisé par un espace pour générer un tableau de chaînes. - Donnée d'identification de la source d'identité
Lorsqu'un utilisateur se connecte à Verify, les attributs de données d'identification source d'identité sont ajoutés à la session de connexion et sont accessibles dans la règle de mappage des demandes.
L'objet de domaineidsuserest disponible sous la forme d'une mappe avec une clé de chaîne et une valeur de tableau de chaînes. Par exemple :
Pour plus d'informations, consultez Fonctions d'attribut.{ "realmName": ["cloudIdentityRealm"], "displayName": ["Jessica J. Hill"], "phone": ["+12324321234"] }- Autres fonctions et opérateurs
Les opérateurs et fonctions standard sont disponibles dans la règle de mappage. Le client HTTP est également disponible pour effectuer des demandes sortantes. Les autres fonctions prises en charge incluent le hachage et les horodatages. Consultez les sections correspondantes dans les fonctions d'attribut.
Objet de retour
Étant donné que cette règle personnalisée doit être interprétée pour générer un contexte d'autorisation, la valeur de retour de cette règle doit être un objet JSON qui doit inclure les propriétés obligatoires suivantes :
| Propriété | Type | Obligatoire ? | Descriptif |
|---|---|---|---|
type |
Chaîne | Oui | Le type indique le type de transaction en cours d'exécution. Par exemple, un engagement de paiement. Cette valeur est représentée dans Verify en tant qu'objectif de confidentialité des données. L'ID objet fourni ou généré par le système est la valeur de type. |
intentID |
Chaîne | Oui | L'ID d'intention doit être indiqué. Il est généralement calculé à partir de requestContext. |
claims |
Objet JSON. La valeur de la propriété JSON peut être de n'importe quel type. | Non | En général, sur autorisation de l'utilisateur, le jeton d'ID généré contient une indication que l'utilisateur a autorisé la transaction identifiée par l'ID de l'intention. claims est un objet JSON ou une mappe, où la clé est le nom de la revendication et la valeur peut être n'importe quelle structure compatible JSON, telle que chaîne, entier, autre objet, tableau ou autres structures. Plusieurs revendications peuvent également être spécifiées. |
scope |
Chaîne | Non | Si la demande est autorisée, cette valeur est ajoutée aux portées accordées. |
Tous les attributs supplémentaires, tels que le montant ou la devise, sont traités comme des attributs personnalisés. Ils peuvent être affichés dans la page de consentement de l'utilisateur à l'aide des macros de modèle correspondantes décrites ultérieurement.
Exemple UK Open Banking
- Un fournisseur de services de paiement (PISP) qui réside sur le Fournisseur tiers et qui lance l'opération de paiement.
- Un serveur d'autorisations ASPSP (Information Service Provider). Dans ce scénario, l'ASPSP est Verify.
- Un serveur de ressources ASPSP qui héberge l'API d'initialisation des paiements.
- Extraire l'ID d'intention.
- Récupérer des informations sur cette transaction à partir du serveur de ressources.
- Extraction de l'ID de l'objet de la demande
- Cet exemple suit la norme UK Open Banking de l'envoi de l'ID de tentative via
claims. La demande d'autorisation entrante contient leopenbanking_intent_iddans les réclamations.
Les réclamations sont extraites et mises à disposition dans le contexte de la demande. Le code utilisé pour extraire la valeur est{ "id_token": { "openbanking_intent_id": { "value": "b508f9df-799b-4120-a13e-5d09f2931fa6", "essential": true } } }requestContext.getValue('claims_idtoken_openbanking_intent_id') - Extraire les informations de transaction
- Les informations de transaction sont stockées dans le serveur de ressources ASPSP (Account Servicing Payment Service Provider), où l'ID de consentement ou d'intention a été généré. Utilisez le client HTTP pour faire une demande au serveur de ressources. La demande suivante en est un exemple.
hc.getAsJSON("https://resource.myaspsp.com/internal/intents/" + context.intentID - Mapper la transaction à une fin de confidentialité et à des réclamations
- Pour saisir les consentements d'ouverture de paiement et de compte Open Banking, vous devez créer des objectifs de confidentialité appropriés. Par exemple, un objectif de confidentialité
payment_initiationdoit être créé pour toutes les demandes de consentement d'initiation de paiement. Cet objectif est ensuite mappé à la propriététypedans l'objet de retour.En outre, pour UK Open Banking, une réclamationopenbanking_intent_iddoit être créée. Les autres informations relatives à la transaction peuvent également être ajoutées à l'objet de retour.{ "type": "payment_initiation", "intentID": "b508f9df-799b-4120-a13e-5d09f2931fa6", "currency": "USD", "amount": "1200.35", "merchant": "Merchant A", "claims": { "openbanking_intent_id": "b508f9df-799b-4120-a13e-5d09f2931fa6" } } - Exemple de règle de mappage
statements: - if: match: "!has(requestContext.claims_idtoken_openbanking_intent_id)" return: null - context: "intentID := requestContext.getValue('claims_idtoken_openbanking_intent_id')" - context: 'intentContext := hc.getAsJSON("https://resource.myaspsp.com/internal/intents/" + context.intentID, { "Authorization": "apikey supersecretapikey" })' - return: >- { "type": context.intentContext.type, "intentID": context.intentID, "currency": context.intentContext.instructedAmount.currency, "amount": context.intentContext.instructedAmount.amount, "merchant": context.intentContext.creditorName, "claims": { "openbanking_intent_id": context.intentID } }
Personnalisation de la page de consentement
Étant donné que l'expérience utilisateur en matière de consentement pour l'autorisation des transactions diffère du consentement standard OAuth et Open ID Connect, une section personnalisée peut être créée dans le modèle de page de consentement. Voir Modifier l'authentification unique pour OpenID les pages.
[RPT purpose_payment_initiation]
<input type="hidden" name="@PRIVACY_SCOPE_PNAME_REPEAT@"
value="@PRIVACY_SCOPE_REPEAT@" privacy-readonly="true" />
<input type="hidden" id="@PRIVACY_SCOPE_PNAME_REPEAT@_state" name="@PRIVACY_SCOPE_PSTATE_REPEAT@"
value="CONSENT_ALLOW" privacy-required="@PRIVACY_SCOPE_REQUIRED_REPEAT@" />
<div id="@PRIVACY_SCOPE_PNAME_REPEAT@_widget" class="bx--form-item" style="width:350px;"></div>
<div class="bx--grid" style="padding-left:0">
<div class="bx--row" style="padding-bottom:6px;">
<div class="bx--col-sm-1">Amount</div>
<div class="bx--col">@PRIVACY_SCOPE_CUSTOM_currency@ @PRIVACY_SCOPE_CUSTOM_amount@</div>
</div>
<div class="bx--row" style="padding-bottom:6px;">
<div class="bx--col-sm-1">Merchant</div>
<div class="bx--col">@PRIVACY_SCOPE_CUSTOM_merchant@</div>
</div>
<div class="bx--row" style="padding-bottom:6px;">
<div class="bx--col-sm-1">Reference</div>
<div class="bx--col">@PRIVACY_SCOPE_ATTRVALUE_REPEAT@</div>
</div>
</div>
[ERPT purpose_payment_initiation]Notez les aspects suivants.- Une nouvelle section reproductible utilisée pour un objectif spécifique de confidentialité des données. Le nom utilisé suit le format
purpose_{purposeID}.purposeIDest l'ID de finalité de confidentialité des données. Cet ID de finalité peut être généré par le système ou fourni par l'utilisateur. - Deux zones de formulaire HTML sont essentielles et sont nommées
@PRIVACY_SCOPE_PNAME_REPEAT@et@PRIVACY_SCOPE_PNAME_REPEAT@_state. La première zone contient l'identificateur Verify de l'enregistrement de consentement. Le deuxième champ contient l'état du consentement. - Les attributs personnalisés renvoyés par la règle avancée peuvent être référencés à l'aide de la macro
@PRIVACY_SCOPE_CUSTOM_{attributeName}@. Par exemple,@PRIVACY_SCOPE_CUSTOM_currency@est remplacé par la valeur de devise renvoyée dans la règle d'intention avancée.