Topic W: Transactional data for Payments and other use cases

[phin10]

Welcome to the discussion on the Transactional data for Payments and other use cases, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document Topic W - Transactional data for Payments and other use cases.

The European Digital Identity Regulation requires the Wallets provide a functionality of strong authentication to play a role of an authenticator for various services, while the Service Providers are obliged to accept them in their (online) services. Consequently, to enable such processes, the Wallet Units should be able to handle transactional data related to an (external) service and a transaction, to enable required functionality, provide a proof of transaction and auditability, as well as ensure compliance with other regulations where necessary (like Payment Services related legislation).

Most of the use cases will use the standard Wallet functionality (meaning w/o the need to involve "transactional data"). However for the following use cases it is necessary handle the transactional data:

• payments,
• remote qualified electronic signature.

In this paper we focus on the cases, where the transactional data are involved.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[sander]

Thank you for sharing the discussion paper and request for feedback. As a general comment, please rename Topic W to “Transactional data for qualified e-signatures or e-seals and other use cases”. Under eIDAS Article 5a(5)(a)(xi) this is a mandatory feature, while payment is not mentioned directly under the Regulation. It is important to keep ensuring that the transactional data requirements are validated with the QES use case at minimum.

[tmielnicki]

Dear Sander, the legal reference for this discussion topic is Article 5f(2), which refers to use of the wallet for strong authentication in various contexts. These include payments and e-signature, which are the most prominent (but not the only ones too).

[sander]

Dear Sander, the legal reference for this discussion topic is Article 5f(2), which refers to use of the wallet for strong authentication in various contexts. These include payments and e-signature, which are the most prominent (but not the only ones too).

Thank you for your comment. I understand that the feature to “accept payment transaction requests” is a useful extension of “use strong user authentication for online identification” as required in Article 5f(2).

However, I suggest to additionally take the mentioned legal requirement on mandatory e-signature creation protocols and interfaces as a basis for Topic W. Framing e-signatures as "another" use case in the topic title insufficiently emphasises this.

[sander]

TD_01 The Wallet SHALL be able to identify and read out transactional data included in a presentation request. Rules for representing the content, structure, rendering and scope of information to be logged in a Wallet Unit is to be defined by an industry sector or a Relying Party in an Attestation Rulebook (according to [Topic 12]).

We are setting this up differently for QES:

• The CSC Data Model (v0.2.0 available for public review) includes two transaction data type specifications.
  • Each has a type URI:
    • https://cloudsignatureconsortium.org/2025/qes
    • https://cloudsignatureconsortium.org/2025/qc-request
  • Based on the received public consultation feedback, for v1.0.0 my current line of thought is:
    • Each type specifies the content: (OID4VP) request parameters and “device-signed items” to return.
    • Each type specifies the structure in terms of at least SD-JWT and mdoc namespaces (governed by CSC as an industry sector collaboration) and X.509 credentials.
    • Each type specifies the rendering required by supported Wallet Solutions.
    • Each type specifies the scope of information to be logged by supported Wallet Solutions.
• Attestation Rulebooks include transaction type support by referring to the CSC-governed namespaces.

To properly support interoperable QES creation, support for the CSC-specified transaction data types should be mandatory for EUDIW. Subsequently, QES providers or related organisations can issue the mentioned “service credentials” with their Attestation Rulebooks, which may vary by QTSP. That is, there is no need to harmonize these specific Attestation Rulebooks across QTSPs since each attestation typically has a single QTSP act as both issuer and verifier.

So while indeed the Attestation Rulebook selects and refers to transactional data rules, these rules are specified in standards such as those of CSC. For EUDIW requirements, it is important to point at these standards to ensure consistent support.

[tmielnicki]

Dear Sander,
thank you for your valuable comments.
First of all, for your information, please note there is a newer version of the proposed HLR set, published earlier this week. Please kindly have a look and revise your comments if needed. Here is the link:
https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/w-transactional-data-for-payments-and-other-use-cases.md#41-topic-20---strong-user-authentication-for-electronic-payments-and-other-use-cases

Regarding the essence, we noted your comment.

[sander]

First of all, for your information, please note there is a newer version of the proposed HLR set, published earlier this week. Please kindly have a look and revise your comments if needed.

Thank you for your response @tmielnicki. I have just checked with v0.95 and my feedback still applies.

In addition, the HLRs now include notes with regard to SD-JWT VC. Note that as far as I’m aware, mdoc also supports these use cases. If there are specific doubts about that, we should discuss these as part of this topic.

[sander]

TD_02 The Wallet Unit SHALL be able to sign the transactional data with the private key of the attestation that was the subject of the presentation request and return it in the response to the Relying Party as a proof of transaction.

Instead of signing, require proving possession of that private key. For example, an ECDH-MAC operation as specified in ISO 18013-5 can also provide a valid proof of possession. There is no reason why the methods for proofs of possession should be different for transactional data than for other presentations.

[tmielnicki]

Dear Sander, please see the new version of this requirement, and let us know your thoughts.

[sander]

Thanks @tmielnicki. In v0.95 the requirement still mentions signing. So the clarifying comment still applies.

[tmielnicki]

Thank you Sanders. This requirement address the need of auditability and a proof of user consent for a given transaction (again in payments/PSD2 there are specific requirements), not really a proof of possession (which is by the way inherently ensured by the wallet core functionality and the presentation protocols). At the same time we believe, that the OpenID protocol meet this requirement by design (and mDL will too if there is transactional data option supported - I understand it is not yet at this moment)

[sander]

TD_04 The Wallet Unit SHALL be able to generate and include in an attestation presentation response a unique, cryptographically random value with the sufficient entropy (authentication code).

What is the use case for this authentication code? Usually the proof of possession is sufficiently randomised to for example detect message replay.

[tmielnicki]

This requirement comes from PSD2 (payment SCA). It might not be necessary indeed, so it is not mandatory to use it, but we think the wallet shall support such mechanism in case the standard mechanisms of the protocols are not sufficient. In any case, please see the latest version of this requirement.

[sander]

As of v0.95, TD_02 notes:

Note: Such a response, signed with the private key of the attestation that was the subject of the presentation request, constitutes as a proof of transaction. This requirement is met by use of key binding in [SD-JWT-VC].

Note that if a Relying Party requires a non-repudiable proof of transaction, requesting a qualified e-signature over the transactional data may be a more appropriate option. For qualified e-signatures, the trust framework is legally well established.

[tmielnicki]

In this case, the transactional data is SAD, and the wallet is just a SIC. So I do not think the qualified signature over the transactional data is needed here.

[sander]

In this case, the transactional data is SAD, and the wallet is just a SIC. So I do not think the qualified signature over the transactional data is needed here.

You refer to the the SAD as defined in the EN 419241 standards. This is not how I see the transactional data being interpreted in the Potential LSP and in CSC. Did you mean to write "data to be signed" instead?

[tmielnicki]

I mean SAD. That's the point - we are not discussing here the wallet being Signature Creation Application - this is another feature of the wallet, covered by another topic in the ARF (see Annex 2 Topic 16 - Signing documents with a Wallet Unit).

[sander]

I mean SAD. That's the point - we are not discussing here the wallet being Signature Creation Application - this is another feature of the wallet, covered by another topic in the ARF (see Annex 2 Topic 16 - Signing documents with a Wallet Unit).

For QES, we are standardising two approaches:

• Internal Signature Creation Application. Here we apply transactional data between the Relying Party and the Wallet, in which the RP specifies what data to sign.
• External Signature Creation Application.

In both use cases, the Wallet likely uses a remote QSCD managed by a QTSP. The QTSP may apply transactional data for the two trust service transactions involved: requesting a qualified certificate and creating a QES.

Both use cases can be applied to sign documents and other transactional data. This is an important reason for eIDAS to regulate QES: to increase trust in digital transactions.

In none of the examples I’ve mentioned above, the transactional data represents SAD from EN 419241. Instead, SAD is QSCD-specific and there is no need to standardise its content. (The method to create SAD is sufficiently standardised in the CSC API but indeed out of scope for Topic W.)

[tmielnicki]

I think all requirements you are referring to are covered by Topic 16. In particular QES_07 refers to CSC API. Here in topic 20 we refer to cases, where it is necessary to include transactional data in a presentation flow. If you think SAD is covered by Topic 16 requirements, then you need nothing from Topic 20. But other use case may need it (eg. payment SCA). In any case, what would be your proposal for the wording of TD_02 (and other HLRs)?
And BTW do you see any need for changes in Topic 16 HLRs?

[stefan-kauhaus]

Regarding TD_04 and the use case being payments, the requirements towards the "authentication code" can be found in PSD2 RTS (https://eur-lex.europa.eu/eli/reg_del/2018/389/oj), Article 4. In summary:

1. The authentication code must be generated by the authenticator -- Article 4 (1). This excludes the approach to utilise the nonce as authentication code, as the nonce is generated and under control of the RP.
2. The authentication code serves as mechanism to prevent replay attacks. Banks must only accept any given authentication code once -- Article 4 (1). This means the produced code must be unique, even when identical input is signed with the same key (to distinguish the user's consent when confirming two or multiple transactions with the same parameters (amount, currency, payee)).
3. The authentication code does not include information about the authentication factors (knowledge, possession, inherence) applied -- Article 4 (2) (a). This is typically met by the wallet architecture.
4. Authentication codes must bot be guessable, including when an attacker has knowledge of any previous such code. -- Article 4 (2) (b). This means that the code should have a certain entropy and e.g. must not simply increment.
5. It must not be able to forge the authentication code -- Article 4 (2) (c). This is typically the case when the code is signed with a private key in possession of the user.

Now, for the current wording of TD_04 (v0.95), I am largely in agreement with some concerns on "this requirement is met by use of key binding in [SD-JWT-VC]":

• The requirement on uniqueness (no. 2 above) should be mentioned explicitly to prevent that wallets produce identical KB-JWTs when signing identical input with the same key,
• SD-JWT is not the only permitted tech/protocol stack. E.g. for mdoc/mDL, obviously the requirement is not met by use of an SD-JWT VC specific feature. (The sentence in general strikes me as a bit simplistic.)

[sander]

The requirement on uniqueness (no. 2 above) should be mentioned explicitly to prevent that wallets produce identical KB-JWTs when signing identical input with the same key

Is this not sufficiently addressed by ECDSA being randomised, and with ECDH-MAC mixing ephemeral random Relying Party input into the shared secret? It would be hard to create identical KB-JWTs or mdoc MSOs with the common algorithms.

[stefan-kauhaus]

Thanks, Sander. Probably yes, but IMHO assumptions on the technical solution should not lead to dropping important aspects from the requirement. This said, I indeed overlooked that TD_04 already mentions "unique". @tmielnicki please disregard my first bullet point. The comment on SD-JWT VC key binding not being the solution for all tech/protocol stacks remains.

[tmielnicki]

Hi Stefan, thanks for your feedback. Do you have your proposal for wording of the TD_04 (and other TD HLRs)? Feel free to drop them here.

[stefan-kauhaus]

The discussion paper (v0.95) makes two important observations in Section 3.1.2: The Registration of an authenticator with the Service Provider before first usage in a transaction context, and the use of functional "service credentials", following the principle of least privilege. I suggest considering to reflect these as TDs.

[tmielnicki]

Dear Stefan, the registration is nothing more than a standard process of issuance of an attestation of attributes. And using the wallet as authenticator is a standard presentation flow. So there is no need of any HLR for this I believe (though we can think of a chapter in ARF main document explaining this).
And I do catch where the issue is around "principle of least privilege", wouldn't you mind to explain more? As said, above the "service credentials" is just a normal attestation, with all the processes around - registration, intended use, user consents to issue and read attestations, data protection rules etc.
Ultimately, would you have your proposals for the text for the additional TDs you have in mind?

[stefan-kauhaus]

Hi Tomasz @tmielnicki,

Herewith my consolidated response on the various aspects (I also discussed with Florian/NOBID in the meantime):

• Registration process: PSD2 RTS actually has requirements that authentication solutions need to be securely associated with the user/account at the ASPSP before usage. But probably you are right and it is sufficient if this requirement stays there; the respective Service Providers (i.e. banks) will be aware of it.

• Principle of least privilege: What we want is to discourage the industry to (mis)use identity attestations (like the PID) for authentication purposes. Whilst there are also regulatory and risk management aspects speaking against that, our main concern is to prevent implementations that lead to over-asking and over-sharing. It should not be necessary to present your PID to e.g. a merchant just to confirm a payment.

• TD_04: While reviewing, we found that one aspect is still missing (references again to PSD2 RTS (https://eur-lex.europa.eu/eli/reg_del/2018/389/oj)):

  The authentication code generated must be specific to the transaction data, and any change to the transaction data must lead to the invalidation of the authentication code generated -- Article 5 (1) (b-d). This again comes "for free" with OID4VP + transaction_data (where the hashed transaction_data input is included in the Key Binding JWT which the wallet signs over with the user's private key), but needs to be mentioned in the requirement.

• TD_01: While it is good to mention the wallet's expected flexibility regarding visualising the transaction data, we feel it is useful to include a baseline expectation as stemming from Articles 5 (1) (a) and 5 (2) (b). This is important as the EU DI wallet and its user interface will not be under direct control of the bank and specific instructions may fail for various reasons.

In summary, we propose the following updates and additions to the TDs:

TD_01: "The Wallet [Unit?] SHALL be able to process and render transactional data included in a presentation request. The Wallet Unit SHALL present this transactional data to the User in a clear, understandable and accurate manner when obtaining the User's confirmation for the transaction. Specific rules for representing the content, structure, rendering and scope of information to be logged in a Wallet Unit are to be defined by an industry sector or a Relying Party in an Attestation Rulebook (according to [Topic 12])."

TD_04: "The Wallet Unit SHALL be able to generate and include in an attestation presentation response a unique, cryptographically random value with the sufficient entropy (authentication code) that is based on or linked to the transactional data returned in the response, according to rules set out in an Attestation Rulebook or information provided to the Wallet Unit in the presentation request. Changes made to the transactional data must result either in a different authentication code or render the link between the transactional data and the authentication code invalid." (Note that we propose to remove the sentence "Note: For payment SCA this requirement is met by use of key binding in [SD-JWT-VC]" from the requirement text for the reasons discussed in this thread.)

TD_new: "Service Providers SHALL implement measures to ensure that attestations used in conjunction with transactional data for authentication purposes are designed in a way that is proportionate to the required functionality. Service Providers SHOULD NOT use attestations designed for identification purposes for the purpose of authentication."

[tmielnicki]

Thank you, we are reviewing your proposals and will get back with feedback.

[tmielnicki]

Dear Stefan,

the general comment is that the "TD" requirements aim to be applicable to various use cases (not only SCA). Therefore, we need to keep them universal, and we envision that use case specific requirements, are to be placed in rulebooks. In conclusion, addressing the (valid) legal requirement for SCA you raised should be ultimately made by proper definition of a "SCA rulebook".

Regarding you proposal for TD_01, we accept in principle and we have adapted your idea in the new text of TD_01.

Regarding your proposal for TD_04, we believe that the protocols natively address your ideas and no changes to HLRs are needed in general. However we have modified and restructured the requirements somehow. The new / final version of the Discussion Paper will be made public soon.

Thank you for your valuable contribution!

[stefan-kauhaus]

Hi Tomasz, thank you for considering our input. We know that requirements engineering can be tricky. :-) We will have a look once the updated wording has been published.