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.)

[Nathall7]

@sgmouy The direct flow between the EUDIW and the issuer bank" I have described is just the basic requirement to comply both with eIDAS2 and PSD2 (and future PSR) without any legal issues for reimbursement requests. This direct flow also requires on line connections due to dynamic linking : for the user for enabling the dynamic authentication with a unique authentication code linked with the payment data, and for the merchant side either online or on proximity in case of payment transactions above thresholds for exemptions. Indeed PSR is also to request dynamic linking for proximity payments. While today proximity payments do not require online connections of both the consumer and the merchant (via the POS) , tomorrow with dynamic lingking that will not be the case... But you know even for banking card, the trend is for enabling contactless payment with PIN , that will solve the issue of dynamic linking ....

I agree with you this "legal flow" is not a convenient journey. For the other approach, embedded/merchant-captured SCA where (i) the EUDIW performs SCA independently of any third party and (ii) the payment approval proof package (including SCA) is attached to the payment message_, they are legal issues to solve : since the SCA shall be under the control only of the issuer bank. even in case of Xpay, a passthrough wallet can be considered as a technical service provider if providing the SCA, and the bank should subcontract and audit the SCA of the Xpay. But In case of an embedded/merchant capture SCA approach, any bank has the right today not to take account of evidences of SCA provided by the merchant and worst in case the bank accepts but the user request a reimbursement, the bank will be obliged to reimburse since no SCA exemption and no evidences to comply with the SCA requirement under the control of the banl. The PSR project should be amended to offer this embedded flow. Since the trilogue between the EU council and the parliament is to start, I do not think that PSR will be amended in the next months.. But the council proposal (released on the 13th of June for the 1st reading) for PSR amendment has included a provision to review PSR only one year after entry into force to take account of digital wallets. Whatever the payment regulations status, there is another big issue for the merchant embedded flow . the direct connection of the EUDIW to the merchant : each merchant would have to register and require an access certificate to each national register of relying parties, and that will depend on each country. In case of banks each national registry will have to accept them as relying parties for payment due to eiDAS regulations that makes that mandatory while for merchants that will not be the case. Even very large on line Plateforms that will will have to be recognised as obliged relying parties for the online access, they will not be recognised as a relying party for payment. What do you think France Titres will do for the French national registry of relying parties ? To sum up merchant / embedded flow requires first new amendments for both the eiDAS and Payment service regulations.

[sgmouy]

Well… I am really not following your reasoning when saying that “direct flows require on line connections due to dynamic linking” or that “proximity payments will require online connection”. Where did you see that proximity flows require dynamic linking or that dynamic linking requires an online connection? There is no such requirement in PSD2 nor in any PSR draft (including the recently released EU Council draft – just take a look at article 85.9) and there is no technical requirement that this be the case as proximity payments work just fine today and dynamic linking can be locally independently implemented by the EUDIW without the need for an internet connection. [Just to clarify, proximity payments usually imply that the payer’s device is offline (rather, only uses NFC connectivity for the payment) whilst the merchant/payee’s terminal remains online so what matters is only the online/offline status of the payer. Full offline/offline payments are for future CBDC interactions and not considered here.]
I will also take issue with the statement that “SCA shall be under the control only of the issuer bank”. Whilst undeniably true in a pre-eIDAS2 environment, this is a questionable statement for EUDIWs when SCA is expressly defined as an EUDIW functionality which are certified to meet High LoA requirements, including for authentication purposes – see eIDAS article 5.d. How can the issuer bank control EUDIW SCA when it is legally mandated to “accept” it under eIDAS article 5f2? This challenges common sense.
However, you are correct in stating that there are many unknowns and that EBA guidance will only be provided in 2027 at the earliest. In light of this it is increasingly clear that the December 2027 deadline for the required acceptance of EUDIW SCA cannot and will not be met – this now looks a certainty. Everything else is up to discussion and interpretation - it could also be that merchant payees – who in fact do not volunteer or decide to rely on EUDIWs when used for payments – will be exempted from the registration requirements – who knows?
All this to say that it is concerning to see that structural embedded assumptions – that can often be challenged - are made but not clarified upfront and seem to be there for the purpose of justifying a particular design outcome.

[Nathall7]

@sgmouy For dynamic linking for proximity payment, that is the proposal of amendement of the EU parliament for the article 85, adopted 23.04.24 : " For the placement of a payment order as referred to in paragraph 1, point (c), through a payer’s device using proximity technology for the exchange of information with the payee’s infrastructure, the authentication of which requires the use of internet on the payer’s device, payment service providers shall apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee or harmonised security measures of identical effect, which ensure the confidentiality, authenticity and integrity of the amount of the transaction and the payee throughout all of the phases of initiation." It is up to the trilogue that is to start now to keep or not this proposal from the parliament". When using strong authentication on the EUDIW , that absolutely requires not only 2 factors but also a dynamic protocol resistant to MiM and replay attack, and so on line protocols.

[Nathall7]

eIDAS does not change the rule. eIDAS2 only requires issuing PSP, upon the voluntary request of the user, to accept EUDIW for identification or authentication when required by contractual obligation. And the contractual obligation of PSD2 and soon PSR is for a SCA under the control of the issuing PSP, at least the EUDIW connected directly to the bank to enable the exchange of proof of consent from the user for SCA delegation to the EUDIW (by the SCA of the bank) and then to receive the authentication code (with dynamic linking) (that cannot be in the hand of the merchant for security reason !) and other metada for evidences of strong SCA performed with the EUDIW to act the user consent.

[sgmouy]

I fear you are missing the point. Proximity payment interactions typically do NOT "require the use of internet on the payer's device" as they rely on NFC or BLE data exchange protocols to interact with payment terminals, so what you refer to simply does not apply. And even if they did the EUDIW could well implement dynamic-linking locally. In short, dynamic-linking does not create an inherent dependency on any third party (including for that matter the ASPSP) and does not inherently require online connectivity. Granted, one may implement dynamic-linking with online interactions to the ASPSP but this is a design choice, not a technical or regulatory requirement.

[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.

[sgmouy]

I am coming late into the discussion - apologies for that. I think the debate about SCA (Strong Customer Authentication) referred to in eIDAS article 5f2 obscures a wider requirement of even more critical relevance for payments - that is of evidencing payer's consent to the payment. Payer's consent is legally what fundamentally matters for payment interactions as Payment Service Providers (banks) are in principle liable when releasing funds that are not authorized by payers. PSD2 and - most unfortunately - the draft Payment Services Regulation (PSR) expected to be enacted later this year and which will replace PSD2 take the view that payment consent processes are managed by PSPs (see PSD2 article 64.2 and draft PSR article 49.6), a position which we find difficult to reconcile with eIDAS article 5f2 (as one knows, it is practically impossible to separate SCA from payment consent). How this difficulty will be solved in unknown today, but it is expected (or rather "hoped") that the European Banking Authority will issue PSR regulatory technical standards guidelines in 2026 or more likely 2027 dealing with the matter.

So it's not just SCA which matters - it clearly does - but in fact it's the wider payer consent's topic. If banks are to "accept EUDIW SCA" as per eIDAS article 5f2 and validly release funds as a result of EUDIW payment authorization, they need to rely on a very clear and robust proof package evidencing payer's consent and which can be presented in court proceedings. This is what truly matters - the rest is nowhere near as relevant. At a more technical level, this approach is implementing the so-called "embedded SCA" model, which is very promising and in our view a better approach to identity-based payments than the current "redirection" (or "decoupled") SCA standard practice relying on redirection the PSPs.

How this proof package evidencing payer's consent is structured is a major unknown today, especially when looking at using the OID4VP "Transaction Data" specifications for the communication protocol between the EUDIW and the ASPSP (payer's bank) which give minimal indications as to how this should happen. It is not clear today that the legal requirement ensuring that PSPs can validly release funds will be met, especially considering the need to ensure that, if SCA is to be "accepted" by banks as per article 5f2, the EUDIW must be solely in charge of SCA and not rely on an unregulated third party for such purpose. The implications of this debate are very important for payment interactions as they will impact in a major way "who does what" in the payment ecosystem. In practice, we recommend using either eIDAS Advanced electronic signatures supported by a Qualified certificate or Qualified Electronic Signatures (probably AdES as an initial step), in all cases with an ASiC file as what matters is the proof package. Indeed, the weaker the proof package, the more likely banks will feel insufficiently protected and require redirection as a way to implement SCA. This would be a missed opportunity.

[phin10]

Thank you for your response.

Please note we have added to the ARF roadmap a new topic AA - Support of Electronic Payments Customer Authentication (SCA) with the Wallet. The discussion paper on this topic is planned for release on 17 September 2025.

We will also open a discussion thread on this topic AA.