Skip to content

Commit

Permalink
fix(rfc-008) validation rules
Browse files Browse the repository at this point in the history
  • Loading branch information
@ed-curran @lalc
ed-curran authored and lalc committed Dec 12, 2024
1 parent 3644f83 commit 484b9c6
Showing 1 changed file with 22 additions and 21 deletions.
43 changes: 22 additions & 21 deletions payment-rfcs/ewc-rfc008-payment-data-confirmation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,8 @@ The following are the pre-requisites for this RFC:

## 4.1 Authorisation request

The authorisation request defined in EWC RFC 002 [3] is extended to support the new parameter **<code>transaction_data</code></strong>. This enables a binding agreement between the user's identification/authentication and authorisation (see [Chapter 5.1 - Presentation Definition](#6-1-presentation-definition-6)) to complete confirmation of a payment transaction. It is defined as an array of strings, each of which is a base64 encoded JSON object containing a typed parameter set with details about the transaction that the Verifier requests the individuals to authorise. The <strong><code>transaction_data</code></strong> object includes the following parameters:
The authorisation request defined in EWC RFC 002 [3] is extended to support the new parameter <code>transaction_data</code></strong>. This enables a binding agreement between the user's identification/authentication and authorisation (see [Chapter 5.1 - Presentation Definition](#6-1-presentation-definition-6)) to complete confirmation of a payment transaction. It is defined as an array of strings, each of which is a base64 encoded JSON object containing a typed parameter set with details about the transaction that the Verifier requests the individuals to authorise.
The <strong><code>transaction_data</code></strong> parameter must contain a transaction data object (base64 encoded JSON object) that includes the following properties:

<table>
<tr>
Expand Down Expand Up @@ -197,39 +198,39 @@ The authorisation response, as defined in EWC RFC 002 [3], is extended to includ

## 5.1 Holder Wallet

The holder wallet must display all attributes (keys and values) contained in the <strong><code>payment_data</code></strong> object to the user as part of releasing the PWA credential and obtaining an explicit user action, signalling they confirm the details presented. It may localise (translate) keys, localise (adapt) number formats and replace or amend currency codes with symbols where appropriate and unambiguous.
The holder wallet must display all attributes (keys and values) contained in the <strong><code>payment_data</code></strong> object to the user as part of releasing the PWA credential and obtaining an explicit user action, signalling they confirm the details presented. It may localise (translate) keys, localise (adapt) number formats and replace or amend currency codes with symbols where appropriate and unambiguous.

## 5.2 Verifier
To verify the VP token received in the presentation response, the verifier needs to have the following information.
This information may have originated from themselves, or been relayed to them by the intermediary in a three-party model:

The integrity and authenticity of the payment data can be verified by the party who knows the public key of the key pair whose possession was proven by the user when the Payment Wallet Attestation was issued as per EWC RFC 007 [5].
* The base64url encoded <strong><code>transaction_data</code></strong> string that was sent to the wallet as part of the authorization request.
* In a three party model - The original input from the user on the payment details, i.e. payee, amount, currency at least, plus any optional parameters. Obtained from the intermediary through industry-specific protocols like 3DS or open banking APIs.

The verifier further needs to have the following information, either directly from the wallet or relayed by the intermediary in a three-party model:
With this information at hand, plus the VP token presented by the wallet, the verifier performs the following:

* The PWA issued into the user’s wallet and corresponding to the funding source (card or account) in question was presented from the user’s wallet and signed by the user.
* The <strong><code>transaction_data</code></strong> object was constructed and sent to the wallet as part of the authorization request.
* The key-binding JWT incl. the hash of the <strong><code>transaction_data</code></strong> object.
* The original input from the user on the payment details, i.e. payee, amount, currency at least, plus any optional parameters. In a two-party model, the user typically inputs this data into a form the bank presents in their online or mobile banking. In a three-party model, the intermediary relays this data, which he has agreed with the user, through industry-specific protocols like 3DS or open banking APIs.
1. Validate the VP Token as described in OpenID4VP [4] for the IETF SD-JWT VC credential format.
* This should include validating the key binding JWT, as a PWA is always bound to a key.
* This should include checking that the timestamp <code>(iat</code>) in the key binding JWT is close (e.g. ±5 minutes) to receiving the input from the user (two-party model) or intermediary (three-party model), respectively.
2. Validate the `transaction_data`
* Validate that the original base64url encoded <strong><code>transaction_data</code></strong> string results in the same hash value when hashed with the given function as the hash contained in `transaction_data_hashes` in the key binding JWT.
* In a three party model - Validate that the payment data in the <strong><code>transaction_data</code></strong> string (once decoded) correspond to the original input from the user obtained through the intermediary.
3. Validate the suitability of the PWA
* Ensure that the PWA was issued by a suitable entity, most likely the issuer should be the same entity as verifier.
* Ensure that the PWA is valid for the funding source (card or account) in question (including non-revoked). Most likely the contents of the PWA can be cross-referenced against the verifiers internal records.

With these details at hand, the verifier performs the following validations:

1. It checks by working with the public key it has on record that the Payment Wallet Attestation and key binding JWT have been presented by the same user to whom the PWA has been issued.
2. It checks by comparing its own records to ensure that the PWA is valid for the funding source (card or account) in question (including non-revoked).
3. It checks that the <strong><code>transaction_data</code></strong> object results in the same hash value when hashed with the given function as the hash contained in the key binding JWT.
4. It checks that the transaction details in the <strong><code>transaction_data</code></strong> object correspond to the values obtained from the user or through the intermediary.
5. It checks that the timestamp <code>(iat</code>) in the key binding JWT is close (e.g. ±5 minutes) to receiving the input from the user (two-party model) or intermediary (three-party model), respectively.

In addition to the above, the verifier may want to validate the user’s Wallet Unit Attestation. This part is outside the scope of this specification. Please see EWC RFC 004 [10] for further details.


# 6.0 Schema definitions

## 6.1 Presentation definition

Below is a non-normative example of a presentation definition to request the Payment Wallet Attestation by specifying the credential type. If the relying party has further information about other attribute values, additional constraints may be used to identify a particular PWA in the user’s wallet.

The id of the input descriptor requesting the PWA, here `7c94e62d-82c2-41d7-a649-6c204bf59d1c`, should be referenced in `credential_ids` of the authorization request.
```json
{
"id": "7c94e62d-82c2-41d7-a649-6c204bf59d1c",
"id": "8dd03977-74e4-4b10-ad6d-05a681f44fc9",
"format": {
"vc+sd-jwt": {
"alg": [
Expand Down Expand Up @@ -320,11 +321,11 @@ Below is a non-normative example of a key-binding JWT with transaction data:

5. EWC RFC 007: Payment Wallet Attestation - v1.0. Available at: [https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc007-payment-wallet-attestation.md](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc007-payment-wallet-attestation.md) (Last Accessed: 10 Nov, 2024)

6. EWC: Payment Authentication (SCA) using EU DI Wallets – Implementation Guide. Available at: [https://github.com/EWC-consortium/eudi-wallet-rfcs/tree/main/payment-rfcs/implementation-guides](https://github.com/EWC-consortium/eudi-wallet-rfcs/tree/main/payment-rfcs/implementation-guides) (Last Accessed: 15 Nov, 2024)
6. EWC: Payment Authentication (SCA) using EU DI Wallets – Implementation Guide. Available at: [https://github.com/EWC-consortium/eudi-wallet-rfcs/tree/main/payment-rfcs/implementation-guides](https://github.com/EWC-consortium/eudi-wallet-rfcs/tree/main/payment-rfcs/implementation-guides) (Last Accessed: 15 Nov, 2024)

7. European Parliament and Council, 2024. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, L 1183, pp. 1–45. Available at: [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401183#d1e38-1-1](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401183#d1e38-1-1) (Last Accessed: 15 Nov, 2024)
7. European Parliament and Council, 2024. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, L 1183, pp. 1–45. Available at: [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401183#d1e38-1-1](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401183#d1e38-1-1) (Last Accessed: 15 Nov, 2024)

8. European Parliament and Council, 2015. Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC. Official Journal of the European Union, L 337, 23.12.2015, p. 35–127. Available at: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366) (Last Accessed: 15 Nov, 2024)
8. European Parliament and Council, 2015. Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC. Official Journal of the European Union, L 337, 23.12.2015, p. 35–127. Available at: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366) (Last Accessed: 15 Nov, 2024)

9. W3C: Payment Request API, Editor’s Draft 09 September 2024. Available at: [https://w3c.github.io/payment-request/#paymentcurrencyamount-dictionary](https://w3c.github.io/payment-request/#paymentcurrencyamount-dictionary) (Last accessed: 18 Nov 2024)

Expand Down

0 comments on commit 484b9c6

Please sign in to comment.