Topic AA - Support of Electronic Payments Customer Authentication (SCA) with the Wallet

[phin10]

Description
Support of Electronic Payments Customer Authentication (SCA) with the Wallet needs to be discussed further. Intention is to draft and finalise the minimal needed high level technical requirements for the ARF.

Publication discussion paper
19 September 2025

Link to discussion paper
Link

Discussion close
Three weeks later.

[G2Longeaux]

Hi, Phin 10
Thank you for initiating the topic
Could you tell us why the "Link'" link does not work, and when the SCA Discussion paper will be available, please?
Guillaume, FBF

[phin10]

Hi Guillaume, the document is in progress and will be published today or tomorrow morning. The link will work then. Sorry for this unclarity.

Paul

[phin10]

First discussion paper published

[stefan-kauhaus]

Dear ARF team,

Thank you for preparing the AA discussion paper. I would like to offer the following views/comments:

Question 1: Should the Wallet Unit be able to validate if the transaction data type is permitted for a given SUA attestation type and conforms to the transaction data type schema?

A strong yes from my side. Let's consider the opposite: If such a control is missing, then any (including malicious) Relying Party will be able to invoke "confirm payment" or "log in to your bank" screens in the user's EUDIW by combining the respective transaction data type with a request for any, including non-related, attestation. If that RP then serves some well-faked pages to the user (e.g., "Login successful. By the way, you must update your password. Enter current password here: ___"), this will allow for very powerful phishing attacks.

That said, this check alone will likely not be enough, as we can assume that the certificate/registrar regime to limit RPs regarding which attestations they can request will not be perfect in the field, and some fraudsters will slip through. It therefore needs to be combined with a robust 'embedded disclosure policy' feature which allows issuers to exercise control over which RPs can request their SUA attestations. HLR EDP_07 of Topic 43 in Annex 2 currently only requires the Wallet Unit to show a Deny or Allow dialogue to the user in case the RP does not match the policy. I therefore propose that for SUA attestations, Wallet Units should enforce these policies.

[david-bakker]

Regarding the first point: I agree as well, and in fact I think that nobody doubts that a Wallet Unit must verify this. Suitable requirements must be included in the Technical Specification that we will prepare for the EC-defined SUA attestation type(s).

Regarding the second point I can only give you some personal musing at the moment: The topic of whether or not an EDP should be enforced by the Wallet Unit was discussed heavily in the comitology, and I doubt that the Commission will want to re-open that discussion. Enforcing it only for SUA attestations runs into challenges as well. In general, we believe a Wallet Unit shall handle all attestations in the same manner; otherwise, there will no end to requests from Attestation Providers that have specific requirements regarding the handling of their attestation type.

[senexi]

One important aspect missing in this discussion is the topic of fraud signals from the perspective of a payment service provider. The financial sector today uses advanced analytics techniques together with a rule-based holistic approach across service domains collecting and analysing user transaction data to be able to react on fraudulent behaviour. These kinds of systems are depending on collecting user audit events with information from different service domains, channels, client applications, devices, etc to be able to get a holistic view of user activities over time and risk score a particular transaction.
Example of the capabilities on the client side of Applications and client detection mechanisms used today are:

• Device detection with device information (OS, version, etc.)
• Behavioural Intelligence with behavioural information
• Device Fingerprinting with device fingerprint from device environment
• IP geolocation
• VPN detection - determines if a user is leveraging a VPN to conceal their identity.
• Incognito mode detection - detects if a user is trying to hide their identity or history.
• Device rooted detection - detects if the device has been tampered with, resilience to reverse engineering and tampering attempts.
• Emulator detection - ensuring the request is coming from a physical device.
• Deepfake Detection - ensuring a real person behind biometrics.

The revised eIDAS Regulation, which guides the ARF's development, does not address the use of external data to combat fraud. In fact, it includes strict privacy limitations, particularly for Wallet Providers. As per Article 5a14, Wallet Providers are restricted from collecting unnecessary information about a wallet's use, or combining personal data from the wallet with data from other services without the user's explicit request. Therefor this is not only a technical issue, but also a regulatory one.

The integration of the EUDI Wallet as an optional authenticator must be carefully managed to avoid any dilution of the robust security measures currently implemented by the banking sector.

[stefan-kauhaus]

To put this on a regulatory footing, the PSD2 RTS include the following generic requirement (https://eur-lex.europa.eu/eli/reg_del/2018/389/art_2):

General authentication requirements

1. Payment service providers shall have transaction monitoring mechanisms in place that enable them to detect unauthorised or fraudulent payment transactions for the purpose of the implementation of the security measures referred to in points (a) and (b) of Article 1.
   Those mechanisms shall be based on the analysis of payment transactions taking into account elements which are typical of the payment service user in the circumstances of a normal use of the personalised security credentials.

2. Payment service providers shall ensure that the transaction monitoring mechanisms take into account, at a minimum, each of the following risk-based factors:
   (a) lists of compromised or stolen authentication elements;
   (b) the amount of each payment transaction;
   (c) known fraud scenarios in the provision of payment services;
   (d) signs of malware infection in any sessions of the authentication procedure;
   (e) in case the access device or the software is provided by the payment service provider, a log of the use of the access device or the software provided to the payment service user and the abnormal use of the access device or the software.

Specifically the malware detection requirement under letter (d) will be hard to meet for banks if there is no additional data coming from the wallet.

[david-bakker]

Within the EUDI Wallet ecosystem, the general approach regarding security and trust is that the Wallet Provider is responsible for ensuring the security of its Wallet Units continually during their lifetime. If the security of a particular Wallet Unit is jeopardized (for whatever reason) then the Wallet Provider must revoke the Wallet Unit by revoking its WUA. Other entities in the ecosystem, especially Attestation Providers and Relying Parties, have to trust the Wallet Providers in this regard. They do not get independent fraud signals directly from the Wallet Unit. This is a rather fundamental assumption for the security model of the EUDI Wallet, and I don't think it will be changed, to be honest.

What this means is that Wallet Providers can introduce some or all of the "capabilities on the client side" that @senexi lists above. I think it's quite reasonable to argue that such information is needed by the Wallet Providers to carry out their responsibilities regarding the Wallet Unit security. However, Attestation Providers (in particular banks and PSPs) would not receive such information directly. Instead, they will monitor the security status of each Wallet Unit to which they have issued a payment credential by regularly verifying that the corresponding WUA is not revoked.

Getting to the requirements that @stefan-kauhaus quotes: As far as I can see, the PSPs can implement the mechanisms under 1 without any involvement of the Wallet Providers, correct? These mechanisms just work on the basis of the contents of the payment transaction they receive.

For the mechanisms under 2: the PSPs in fact just outsource this responsibility to the Wallet Providers. I understand that this will lead to all kinds of interesting legal and contractual questions. But those questions should not be (very much) different from similar questions that e.g. PID Providers may encounter regarding their legal obligations to keep their PIDs secure. We should focus on getting clarity on these questions in general, rather than trying to have different technical measures for payment credentials relative to other types of credentials.

[stefan-kauhaus]

Hi David,

Thanks for your comments. As a "foreword", I'd say that it is important to keep in mind that banks are equally obliged to adhere to PSD2 just as they (will) need to adhere to eIDAS2, which means that the solutions we come up with need to meet the combined requirements of both regulatory frameworks, and there is no prioritisation between the two. Your starting point of the EU DI wallet categorically treating every entity and every use case the same is understandable and noble (really!), but it remains to be seen if this can be upheld if the demand is not just some attestation issuer's 'nice-to-have wish list' but rather coming from another EU-level regulation.

Other entities in the ecosystem, especially Attestation Providers and Relying Parties, have to trust the Wallet Providers in this regard.

The current PSD2 regime does not permit banks to do this. For better or worse, PSD2/RTS are very detailed (as highlighted with e.g. the point 2 (d) above), and of course the framework does not have any notion of the EU DI wallet i.e. the concept of a mandatory-to-accept, third-party authenticator not under the bank's control. We can hope for PSD3/PSR and its renewed RTS to fix this eventually, but right now we are where we are.

As far as I can see, the PSPs can implement the mechanisms under 1 without any involvement of the Wallet Providers, correct?

Correct, I just cited the entire article for completeness.

For the mechanisms under 2: the PSPs in fact just outsource this responsibility to the Wallet Providers.

You made my day. :-) Two comments on this: 1/ having outsourcing agreements between each of the several thousand banks in the EU and each of the 27+ wallet providers will not be feasible and 2/ even if this was possible, given that the outcome of such outsourcing contract negotiation is not guaranteed, banks would still face the dilemma to have to accept a wallet (by eIDAS2 mandate) even if that wallet (provider) does not agree to implement the necessary safeguards into their solution, meaning that the bank will violate PSD2.

I'm aware that we will not solve this topic here and FYI this very aspect around the friction between PSD2 and eIDAS2 has been a central point of feedback from the LSPs to CONNECT with a request to also discuss with FISMA.

[david-bakker]

I really understand the problems the banks have. To be frank, the mandatory acceptance of EUDI Wallets by banks is one of several areas in the Regulation where law makers obviously did not understand (or at least did not fully consider) the complexity of what they were mandating. And of course I'm willing to discuss anything we can do to make sure we make things as good as possible. Nothing of what I say is carved in stone; I'm just trying to explain what the overall approach to security of the EUDI Wallet has been thus far. And also to see how far we can get with that approach in the case of banks.

[stefan-kauhaus]

Question 2: Which of the following requirements should turn into HLRs?

First of all, I agree that -- as suggested -- the relevant functional requirements in this section 4.2 should be covered in a/multiple Technical Specification(s).

In terms of HLRs, to me the following aspects appear to be specific/noteworthy and would benefit from being called out as requirements:

• 4.2.1 item "Payment Instrument Identification": If seen a bit more generic, the interesting requirement here is that for SUA Attestations, the wallet must be able to combine information from both the attestation which is requested to be presented and the transaction data which comes with the presentation request on a single confirmation screen/in a single confirmation context in a meaningful way.
• 4.2.2 item "Contextual Call-to-Action": The important requirement here is that the confirmation action text (e.g., the button label), must be under control of the SUA attestation issuer. Specifically, it may not be determined by the Relying Party, in order to prevent malicious RPs from tricking users into certain actions by setting wrong or misleading labels on the confirmation screen.
• 4.2.2 item "Anti-fraud guidance": Similar to the above, again the requirement is that this security hint must be controlled by the issuer and cannot be set by the RP.

[tmielnicki]

Not decided yet, but it seems that the Technical Specification will be the best place to put such requirements. The bullet point 2 particularly must be further discussed however to see how the "control of the SUA attestation issuer over the button label" should look like. In principle the "issuer control" is intended to be done via a rulebook possibly.

[stefan-kauhaus]

Thanks Tomasz, yes, let's have subsequent discussions how these requirements can be solved for and whether this results in new functional requirements and solutions (--> TS) or if sufficient functionality is already in place and just needs to be described (--> attestation rulebook), or both (rulebook refers to new TS).

[stefan-kauhaus]

As part of the work produced by EWC and NOBID on payments with EUDIWs, we have identified one functional requirement for wallets to improve security when it comes to man-in-the-middle attacks:

"When receiving a request for an SUA Attestation including transaction data, the wallet SHALL bind its response to the requesting Relying Party e.g. by putting the RP's public key, which the wallet knows and has validated as part of the signed Authorization Request as per HAIP, into the 'aud' claim of the KB JWT accompanying the SUA Attestation."

We imagine that this requirement may be useful also as a general rule (i.e. not only in the context of SUA attestations/transaction data), but we are unaware whether it has already been captured elsewhere. We are happy to engage in a discussion to find an appropriate "home" for this requirement.

[david-bakker]

"When receiving a request for an SUA Attestation including transaction data, the wallet SHALL bind its response to the requesting Relying Party"

Both OpenID4VP and ISO 18013-5 already do that:

• OpenIDVP requires the verifier to include a nonce in the authorization request, which must then included by the Wallet in the Key Binding JWT defined in SD-JWT VC. This Key Binding JWT is then signed by the Wallet.
• ISO 18013-5 requires the reader to include an ephemeral (i.e., different for each transaction) public key in the mdoc request. Apart from being used to establish a session key, the mdoc also includes that reader public key in the Session Transcript. The Session Transcript is then signed by the mdoc.

So this requirement is already covered by the ARF because we require support for either ISO/IEC 18013-5 or OpenID4VP.

[stefan-kauhaus]

Hi David,

Thanks. For the OID4VP variant, I am not a security expert but to my understanding, binding the response to a nonce does not sufficiently protect against MITM. Anyhow, I revisited the spec and luckily, things have developed in a positive way:

https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html#section-5-2.3:

For signed requests, the Verifier MUST use, and the Wallet MUST accept the Client Identifier Prefix x509_hash as defined in Section 5.9.3 of [OIDF.OID4VP].

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-5.9.3-3.6.1:

x509_hash: When the Client Identifier Prefix is x509_hash, the original Client Identifier (the part without the x509_hash: prefix) MUST be a hash and match the hash of the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key (...). The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate.

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#appendix-B.3.6-3:

The following requirements apply to the nonce and aud claims in the Key Binding JWT:

• the nonce claim MUST be the value of nonce from the Authorization Request;
• the aud claim MUST be the value of the Client Identifier, except for requests over the DC API where it MUST be the Origin prefixed with origin:, as described in Appendix A.4.

So, effectively, they have now incorporated what we had in mind.

[stefan-kauhaus]

Dear ARF team,

Thank you for hosting the second consultation call on 1st October and preparing the updated AA discussion paper v0.95.

Question 3: Are the native mechanisms of SD-JWT and mDoc sufficient to deliver authentication code? Is there a need for change of HLR(s) in this respect?

For SD-JWT VC over OID4VP, I believe the native capabilities of the protocol are sufficient given that the spec defines in detail how incoming transaction data needs to be handled and included in the response's KB JWT.

For mdoc/mDL, I took from yesterday's call that we may need to profile the spec as part of the upcoming TS12 to guarantee uniform handling of transaction data in the wallet's response and specifically compliance with Dynamic Linking. Happy to contribute.

[david-bakker]

Hi Stefan, thank you (and Olivier) as well for your contributions. It's great to have people clearly articulate what they need from the Wallet, even if we sometimes cannot fulfill those requirements or push back a little :-).

Regarding ISO/IEC 18013-5: Indeed the Working Group is working on an appendix explaining how to handle transaction data. I will send you a draft for your reference.

[stefan-kauhaus]

As an outcome of the first consultation call on 24th September, there was broad consensus in the group that we need to introduce provisions to prevent the scenario where a (malicious) Relying Party will be able to invoke "confirm payment" or "log in to your bank" screens in the user's EUDIW by combining the respective transaction data type with a request for any, including non-related, attestation.

To address this topic, the AA discussion paper v0.95 introduces a new SUA_07.

For the record, I would like to note that the wording of this HLR does not reflect the group consensus because it fails to meet the objective, given that it leaves the wallet's behaviour undefined for the non-happy path.

I propose a more detailed handling as follows:

• If the wallet detects that incoming transaction data does not conform to the related technical specification and/or attestation rulebook (i.e. that it violates the schema), it should not proceed to process this data, as it does not even know how to properly present such undefined data to the user in the confirmation screen UI.
• If the transaction data conforms to the schema but a wrong attestation type has been requested with it, the wallet should at least warn the user and obtain explicit approval before continuing processing.

The second point is in line with the current solution for embedded disclosure policies, which is a comparable scenario as they aim to protect the user from presenting an attestation to an unwanted relying party. The warning mechanism is specified in EDP_07.

[david-bakker]

Hi @stefan-kauhaus ; thanks, we will take this feedback into account.

Specifically regarding your last bullet point: I don't understand how this situation could happen. A schema is only defined in relation to a specific attestation type. So if the Wallet Unit receives a request that contains transaction data, it will first look at the requested attestation type, then dig up the schema containing the specification of the transaction data for that attestation type, and lastly verify that the received transaction data complies with that specification.

So, to my mind, 'attestation type is wrong' or 'transaction data is wrong' are actually the same, since transaction data can only be wrong for a specific attestation type.