Open Baking-Absichts-ID für OpenID Connect-Anforderungszuordnung

Online bearbeiten

Wenn eine Anwendung eines anderen Anbieters eine Transaktion einleiten möchte, für die eine Benutzerberechtigung erforderlich ist (z. B. eine Überweisung), verwendet sie eine API, die vom Finanzinstitut oder von der Bank bereitgestellt wird, um die Details der Transaktion zu registrieren. Sie registriert beispielsweise den Betrag der Transaktion und den Typ der Währung. Dieser Prozess wird manchmal als "Erfassung einer Zahlungsabsicht" bezeichnet. Die API antwortet mit einer Absichts-ID, die in den UK Open Banking-Spezifikationen auch als Zustimmungs-ID bezeichnet wird. Die Anwendung startet den Datenfluss für einen OAuth-Berechtigungscode, um die Benutzerberechtigung abzurufen, die als Benutzerzustimmung aufgezeichnet wird.

Da die Nutzdaten, die die Transaktion darstellen, und der Prozess zum Einschließen der Absichts-ID in die Berechtigungsanforderung nicht klar definiert sind, kann ein Administrator IBM® Verify verwenden, um mithilfe einer angepassten Regel ein Script für die folgenden Aktionen zu schreiben.
  • Extrahieren Sie die Absichts-ID aus der Anforderung.
  • Rufen Sie die Informationen zum Absichtskontext ab, normalerweise durch Aufrufen der Bank-API.
  • Wählen Sie aus, wie die Berechtigung in id_token als Anforderung oder Geltungsbereichswert dargestellt werden soll.
Die angepasste Regel basiert auf der Syntax, die unter Steuerprogramm für mehrzeilige Regeln beschrieben wird. Einfachere Regeln können aus einer Zeile bestehen und müssen nicht im YAML-Format geschrieben werden.

Verfügbare Eingabeobjekte

Da diese angepasste Regel nach der Authentifizierung, aber vor der Autorisierung ausgeführt wird, enthalten die verfügbaren Informationen nicht alle möglichen Domänenobjekte. Sie sind auf die folgenden Typen beschränkt:

HTTP-Anforderungskontext
Wenn sich ein Benutzer an Verify anmeldet, kann in der Regel zur Anforderungszuordnung auf den Kontext der eingehenden HTTP-Anforderung zugegriffen werden. Alle OAuth-Anforderungsparameter, wie claims oder scope, sind in dieser Version von requestContext verfügbar. Der allgemeine Aufbau und die Verwendung von requestContext werden im Abschnitt „ HTTP -Anforderungskontext“ des Dokuments „ r_attr_functions.html “ beschrieben.
Zur Vereinfachung des Zugriffs werden bestimmte Werte vorab in requestContext berechnet. Der Anforderungsparameter claims wird im Allgemeinen wie im folgenden Beispiel als JSON-Code dargestellt.

{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

Da der Zugriff auf diese JSON-Datei umständlich sein kann, weist der in requestContext verwendete Schlüssel das Format claims_claimType_claimName auf. claimType ist entweder userinfo oder idtoken. Beachten Sie den fehlenden Unterstrich. Im vorherigen Beispiel kann der Wert claim_name mithilfe von requestContext.getValue('claims_idtoken_claim_name') abgerufen werden.

In ähnlicher Weise wird scope berechnet und durch ein Leerzeichen getrennt, um ein Zeichenfolgearray zu erstellen.

Identitätsquellenberechtigungsnachweis

Wenn sich ein Benutzer an Verify anmeldet, werden die Attribute der Berechtigungsnachweise der Identitätsquelle zur Anmeldesitzung hinzugefügt; auf diese kann in der Regel zur Anforderungszuordnung zugegriffen werden.

Das Domänenobjekt idsuser ist als Zuordnung mit einem Zeichenfolgeschlüssel und einem Zeichenfolgearraywert verfügbar. Beispiel:

{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
Weitere Informationen finden Sie unter r_attr_functions.html.
Weitere Funktionen und Operatoren

Die Zuordnungsregel enthält Standardoperatoren und -funktionen. Der HTTP-Client ist auch für abgehende Anforderungen verfügbar. Weitere unterstützte Funktionen sind Hashing und Zeitmarken. Siehe die entsprechenden Abschnitte im „ r_attr_functions.html “.

Objekt zurückgeben

Da diese angepasste Regel zur Erstellung eines Berechtigungskontexts interpretiert werden muss, muss der Rückgabewert dieser Regel ein JSON-Objekt sein, das die folgenden obligatorischen Eigenschaften enthalten muss:

Eigenschaft Typ Erforderlich? Beschreibung
type Zeichenfolge Ja Der Typ gibt den Typ der Transaktion an, die ausgeführt wird. Beispiel: Ein Zahlungsstart. Dies wird in Verify als Datenschutzzweck dargestellt. Die vom System bereitgestellte oder generierte Zweck-ID ist der Wert von type.
intentID Zeichenfolge Ja Die Absichts-ID muss angegeben werden. Sie wird normalerweise aus requestContext berechnet.
claims JSON-Objekt. Der JSON-Eigenschaftswert kann einen beliebigen Typ aufweisen. Nein In der Regel enthält das generierte ID-Token bei der Benutzerberechtigung einen Hinweis darauf, dass der Benutzer die Transaktion autorisiert hat, die durch die Absichts-ID angegeben wird. claims ist ein JSON-Objekt oder eine JSON-Zuordnung, wobei der Schlüssel der Name der Anforderung ist und der Wert eine beliebige JSON-kompatible Struktur sein kann, z. B. eine Zeichenfolge, eine Ganzzahl, ein anderes Objekt, ein Array oder andere Strukturen. Es können auch mehrere Anforderungen angegeben werden.
scope Zeichenfolge Nein Wenn die Anforderung berechtigt ist, wird dieser Wert den erteilten Bereichen hinzugefügt.

Alle zusätzlichen Attribute, wie z. B. Betrag oder Währung, werden als angepasste Attribute behandelt. Sie können auf der Seite für die Benutzereinwilligung mithilfe der entsprechenden Vorlagenmakros angezeigt werden, die später beschrieben werden.

UK Open Banking-Beispiel

Damit eine Zahlung gestartet werden kann, muss zuerst eine Absicht erfasst werden. An diesem Szenario sind folgende Teilnehmer beteiligt:
  • Ein PISP (Payment Initiation Service Provider), der sich beim Drittanbieter befindet und die Zahlungstransaktion einleitet.
  • Ein ASPSP-Berechtigungsserver (ASPSP = Account Information Service Provider). In diesem Szenario ist der ASPSP Verify.
  • Ein ASPSP-Ressourcenserver, auf dem die API für die Zahlungsinitialisierung gehostet wird.
Der PISP leitet den Benutzer um, um die Berechtigung für den Berechtigungsserver mit der Absichts-ID auszuführen. Der Berechtigungsserver muss die folgenden Tasks ausführen:
  1. Die Absichts-ID extrahieren.
  2. Informationen zu dieser Transaktion vom Ressourcenserver abrufen.
Von dieser angepassten Regel werden beide Operationen ausgeführt.
Absichts-ID aus Anforderung extrahieren
Im folgenden Beispiel wird der UK Open Banking-Standard zum Senden der Absichts-ID über claims veranschaulicht. Die eingehende Berechtigungsanforderung enthält openbanking_intent_id in den Anforderungen.

{
	"id_token": {
		"openbanking_intent_id": {
			"value": "b508f9df-799b-4120-a13e-5d09f2931fa6",
			"essential": true
		}
	}
}
Die Anforderungen werden extrahiert und im Anforderungskontext verfügbar gemacht. Zum Abrufen des Werts wird der folgende Code verwendet:

requestContext.getValue('claims_idtoken_openbanking_intent_id')
Transaktionsinformationen abrufen
Transaktionsinformationen werden auf dem ASPSP-Ressourcenserver (ASPSP = Account Servicing Payment Service Provider) gespeichert, auf dem die Zustimmungs- oder Absichts-ID generiert wurde. Verwenden Sie den HTTP-Client, um eine Anforderung an den Ressourcenserver zu erstellen. Die folgende Anforderung ist ein Beispiel.
hc.getAsJSON("https://resource.myaspsp.com/internal/intents/" + context.intentID
Transaktion einem Datenschutzzweck und Anforderungen zuordnen
Zur Erfassung von Einwilligungen für die Zahlungsinitiierung und den Kontozugriff für Open Banking müssen relevante Datenschutzzwecke erstellt werden. Beispielsweise muss für alle Zustimmungsanforderungen für die Zahlungsinitiierung ein payment_initiation-Datenschutzzweck erstellt werden. Dieser Zweck wird danach der Eigenschaft type im Rückgabeobjekt zugeordnet.
Außerdem muss für UK Open Banking eine openbanking_intent_id-Anforderung erstellt werden. Die übrigen Informationen zur Transaktion können auch zum Rückgabeobjekt hinzugefügt werden.

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

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

Zustimmungsseite anpassen

Da sich die Benutzererfahrung bei der Einwilligung zur Transaktionsautorisierung von der Standard-Einwilligung bei „ OAuth “ und der OpenID Connect-Einwilligung zum Zugriffsbereich unterscheidet, kann in der Vorlage für die Einwilligungsseite ein benutzerdefinierter Abschnitt erstellt werden; siehe „Single Sign-On für OpenID -Seiten anpassen “.

Beispiel:

[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]
Beachten Sie die folgenden Aspekte.
  • Ein neuer wiederholbarer Abschnitt, der für einen bestimmten Datenschutzzweck verwendet wird. Der verwendete Name weist das Format purpose_{purposeID} auf. purposeID ist die ID des Datenschutzzwecks. Diese Zweck-ID kann vom System generiert oder vom Benutzer bereitgestellt werden.
  • Die beiden HTML-Formularfelder @PRIVACY_SCOPE_PNAME_REPEAT@ und @PRIVACY_SCOPE_PNAME_REPEAT@_state sind von grundlegender Bedeutung. Das erste Feld enthält die Verify-ID für den Zustimmungsdatensatz. Das zweite Feld enthält den Status der Zustimmung.
  • Auf angepasste Attribute, die von der erweiterten Regel zurückgegeben werden, kann mit dem Makro @PRIVACY_SCOPE_CUSTOM_{attributeName}@ verwiesen werden. @PRIVACY_SCOPE_CUSTOM_currency@ wird beispielsweise durch den Währungswert ersetzt, der in der erweiterten Regel für Absichten zurückgegeben wird.