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.

Étant donné que la charge qui représente la transaction et le processus d'inclusion de l'ID de tentative dans la demande d'autorisation n'est pas bien défini, un administrateur peut utiliser IBM® Verify pour exécuter les actions suivantes à l'aide d'une règle personnalisée.
  • 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_token comme valeur de demande ou de portée.
La règle personnalisée est basée sur la syntaxe décrite dans Exécuteur de règle multiligne. Les règles plus simples peuvent être une seule ligne et n'ont pas besoin d'être écrites dans le format YAML.

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 claims et scope, sont disponibles dans cette requestContext. La structure générale et l'utilisation de requestContext sont 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 dans requestContext. Le paramètre de requête claims est 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 requestContext est donc au format claims_claimType_claimName. claimType est userinfo ou idtoken. Notez le trait de soulignement manquant. Ainsi, avec l'exemple précédent, la valeur claim_name peut être obtenue à l'aide de requestContext.getValue('claims_idtoken_claim_name').

De même, scope est 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 domaine idsuser est disponible sous la forme d'une mappe avec une clé de chaîne et une valeur de tableau de chaînes. Par exemple :

{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
Pour plus d'informations, consultez Fonctions d'attribut.
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

Pour commencer un paiement, une intention doit d'abord être déposée. Les participants suivants participent à ce scénario :
  • 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.
Le PISP redirige l'utilisateur pour qu'il effectue une autorisation sur le serveur d'autorisation, ainsi que l'ID de l'intention. Le serveur d'autorisation doit effectuer les tâches suivantes :
  1. Extraire l'ID d'intention.
  2. Récupérer des informations sur cette transaction à partir du serveur de ressources.
Cette règle personnalisée exécute ces deux opérations.
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 le openbanking_intent_id dans les réclamations.

{
	"id_token": {
		"openbanking_intent_id": {
			"value": "b508f9df-799b-4120-a13e-5d09f2931fa6",
			"essential": true
		}
	}
}
Les réclamations sont extraites et mises à disposition dans le contexte de la demande. Le code utilisé pour extraire la valeur est

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_initiation doit être créé pour toutes les demandes de consentement d'initiation de paiement. Cet objectif est ensuite mappé à la propriété type dans l'objet de retour.
En outre, pour UK Open Banking, une réclamation openbanking_intent_id doit ê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.

Par exemple :

[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}. purposeID est 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.