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 may not have understand (or 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.

[cyberphone]

This again highlights the fact that Identity and Payments are two quite different use cases.

In the payment use case the relying party is (usually) the Issuer bank to which the user already have a trusted relation with. In this case it does not seem like a privacy invasion letting the wallet include additional data. Supplying geolocation is a selectable feature in the mobile OS itself. Wallet version/id and mobile OS seem like necessary data to include since this data will change over time. Obsolete Android and iOS versions are often rejected by banks. Emulator and hardware should IMO be dealt with during registration.

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

Hi @david-bakker,

Apologies, I forgot one important aspect. As you can see from the above, for OID4VP/HAIP, these additional protections only kick in if the request is signed. So, for SUA Attestations, we need to explicitly include an HLR that Authzn Requests MUST be signed, in order not to create a loophole.

[david-bakker]

Yes, that's true. This would be something to include in TS12.

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

[stefan-kauhaus]

Hi David,

Fair point. Lastly it's about sequencing in the wallet's business logic. In the LSPs we assumed that the transaction data's type will contain a pointer to the schema, so the wallet could validate the incoming object against that in an isolated manner before looking at the requested attestation type and whether it matches. But I can also see your approach of thinking.

Anyhow, I believe the main point is that if we permit wallets to proceed even in the "unhappy" scenario, we may end up with undefined behaviour in the wallet's confirmation screen UI.

[david-bakker]

Hi David,

Fair point. Lastly it's about sequencing in the wallet's business logic. In the LSPs we assumed that the transaction data's type will contain a pointer to the schema, so the wallet could validate the incoming object against that in an isolated manner before looking at the requested attestation type and whether it matches. But I can also see your approach of thinking.

Thanks for explaining your line of thought. Of course the exact verification flow does not really matter, as long as we can be sure that the requested attestation type is consistent with the provided transaction data.

Anyhow, I believe the main point is that if we permit wallets to proceed even in the "unhappy" scenario, we may end up with undefined behaviour in the wallet's confirmation screen UI.

Personally, I agree that in the unhappy scenario, the Wallet Unit should stop processing, since indeed it's behaviour is undefined.

[Anti-Myon]

SCA in the EUDIW must not fall short of the standards set by FIDO. It should deliver at least a Level of Assurance (LoA) “Substantial” to “High” as required by regulations such as eIDAS and PSD2, and align with the expectations of the financial industry.

Dear ARF team,

While OpenID4VP is an important protocol component, it only addresses part of what a complete SCA solution requires. It does not cover several critical aspects, including:

• Protected environments: Secure key storage and matcher protection, leveraging ROE (Restricted Operating Environments) or Secure Elements (SE) with verifiable statements like key and device attestation.

• Multi-factor authentication: Secure key access with strong user verification and clear indication of the verification method.

• Phishing prevention: Essential safeguards such as origin checks of RPID and non-reusable assertions to mitigate phishing risks.

• Unlinkability: FIDO ensures that public key credentials are exclusively used for authentication with the same entity (identified by the RP ID). This binding not only makes FIDO phishing-resistant but also ensures that credentials are never reused across different Relying Parties, implicitly guaranteeing unlinkability.

• Protected confirmation & user sole control: Attributes (e.g., for payment approval or selective disclosure) must be displayed in a trusted user interface (TUI) that remains secure even if the device’s REE (Rich Execution Environment) is compromised (e.g., by malware or remote-control attacks). See this discussion FIDO for User Sole Contol in the EUDI Wallet #302

• Cross-device access: Support for scenarios where the communication endpoint is on a different device than the one hosting the EUDIW, requiring secure cross-device communication.

Given these broader requirements, FIDO should be considered as a foundation for implementing SCA within the EUDIW. Its proven security properties, wide industry acceptance, and regulatory compliance make it a strong candidate to ensure robust, future-proof authentication.

[Anti-Myon]

Unfortunately, the links provided are private.

Upon reviewing Annex 2 of the ARF, this aspect does not appear to be listed in release 1.4: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-2/annex-2-high-level-requirements

The requirement to indicate the specific authentication method used for each key operation is an explicit and detailed requirement. Ultimately, this must be addressed at the protocol level, for example within OID4VP or comparable specifications. At present, it does not appear to be covered there.

I acknowledge that the ARF is not intended to prescribe implementation details. However, it should still explicitly express the need for such functionality in order to promote adoption and alignment at the protocol layer.
If the ARF already formulates this requirement explicitly, I would appreciate a reference to the relevant section.

The requirement for protected confirmation and user sole control is even more complex. Ensuring that attributes (e.g., payment amounts or selectively disclosed data) are displayed and confirmed within a Trusted User Interface (TUI)—which remains secure even if the Rich Execution Environment (REE) is compromised—depends heavily on OEM-level capabilities. Achieving this consistently and reliably across devices is extremely challenging.

Both aspects -

• per-operation authentication method indication, and
• trusted confirmation under user sole control -

require support at lower technical layers, including key attestation and device (or WTE) attestation mechanisms. These dependencies extend beyond the high-level guidance currently provided in the ARF.

[stefan-kauhaus]

Hi Ben,

Could you point me to where this

requirement to indicate the specific authentication method used for each key operation is an explicit and detailed requirement.

is rooted in PSD2/RTS/EBA Opinions/EBA Q&A? -- I think it's a useful thing to do (as it would also provide risk signals to the bank), however I struggle to find a regulatory source. Thanks!

Best regards,
Stefan

[david-bakker]

Unfortunately, the links provided are private.

Upon reviewing Annex 2 of the ARF, this aspect does not appear to be listed in release 1.4: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-2/annex-2-high-level-requirements

Hi Ben, not sure at all if this solves anything, but please note that the latest version of the ARF is 2.6.0. We update the ARF on roughly a bi-weekly basis. If you use this link, you always get the latest version.

[Anti-Myon]

Hi Stefan,
The requirement to indicate which authentication method was used is rooted in PSD2, the RTS on SCA, and subsequent EBA guidance (see “Final Report” EBA/RTS/2017/02, 23 February 2017, Final Report, Draft Regulatory Technical Standards (https://www.eba.europa.eu/sites/default/files/documents/10180/1761863/314bd4d5-ccad-47f8-bb11-84933e863944/Final%20draft%20RTS%20on%20SCA%20and%20CSC%20under%20PSD2%20(EBA-RTS-2017-02).pdf)), which emphasize that SCA must be based on two independent factors (possession, knowledge, inherence, (i.e. the breach of one element does not compromise the reliability of the other)) and that these factors must be known (Article 2.4), traceable (Article 26 b), and linked to each individual payment authorisation.

For SCA it must be clear which specific knowledge or inherence factor unlocked the possession factor (in this case, the cryptographic key). Under PSD2, this unlock must occur per authorisation, not just per session or per device unlock.

See also page 23 of the 2024 EPC “Payment Threats and Fraud Trends” report:
https://www.europeanpaymentscouncil.eu/document-library/reports/yearly-update-payment-threats-and-fraud-trends-report-0 ( PDF: https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-03/EPC162-24%20v1.0%202024%20Payments%20Threats%20and%20Fraud%20Trends%20Report.pdf )
which requests authentication with linking through a trusted user interface (TUI).
Art 9 of the RTS notably states:
2. Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.

[Anti-Myon]

Unfortunately, the links provided are private.
Upon reviewing Annex 2 of the ARF, this aspect does not appear to be listed in release 1.4: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-2/annex-2-high-level-requirements

Hi Ben, not sure at all if this solves anything, but please note that the latest version of the ARF is 2.6.0. We update the ARF on roughly a bi-weekly basis. If you use this link, you always get the latest version.

Thanks David. I don't see these aspects covered yet.

[sgmouy]

Below are comments jointly provided by Quali-Sign Ltd and SGM Consulting

By way of introduction, our assessment of EUDIW SCA processes is primarily based on our reading of eIDAS article 5f2 stating that (i) EUDIW are capable of performing SCA when requested by the wallet user and (ii) EUDIW SCA must be accepted by banks. We see this as having two major implications:
• When implemented by EUDIWs, SCA must comply with all applicable SCA requirements for payments in order to be accepted – notably dynamic-linking;
• As third parties have no access or audit rights to the internal logs of EUDIWs, a valid and robust proof package of SCA must be produced by the EUDIWs, especially in order to allow banks to legally rely on SCA.

SCA is structurally geared towards evidencing payer’s consent to payment, a legal requirement for ASPSPs allowing them to avoid liability when releasing payers’ funds. In order to be fully effective, the proof package of SCA should legally reverse the burden of SCA proof - from the party claiming that SCA had validly taken place to the party claiming that SCA did not validly take place.
Lastly, SCA as a proof of consent process is operationally and legally distinct from payment validation, which must always remain a prerogative of banks. Approved payments must still be validated by ASPSPs that retain the decision to proceed with the payment – the normal situation - or decline to do so when there are insufficient funds in the payer’s account or they have reasons to believe that the payer is engaging in fraudulent transactions.

On section 3 Use cases
When used in SCA contexts, the “SUA attestation” terms need clarifying. As we understand them - and counter-intuitively - they are not a third-party attestation that SUA/SCA has been implemented by the EUDIW as this is the prerogative of the EUDIW under eIDAS 5f2 but are issued by the wallet user’s bank (ASPSP) and confirm the wallet user as a Payment Services User (PSU) and, optionally also their user’s payment means (IBAN or card) that can be used in connection with SCA processes. For practical purposes, the SUA attestation is attached to the payment message, allowing the ASPSP to recognize the payment instruction received and allocate it to the right PSU and (optionally) their payment means in a timely manner. For example, a relevant SCA attestation would be an IBAN presented as a [Q]eAA.
The paper suggests that the PSU (EUDI wallet holder) may be issued multiple SUA attestations by their bank, for different purposes. We believe this is justified. From a privacy perspective, it is important that any selective disclosure techniques that are employed do not inadvertently disclose to the relying party the number of payment instruments (e.g. cards and bank accounts) that a PSU holds with a specific bank. The use of atomic attestations (i.e. one per payment instrument) may be more appropriate in this context.
The distinction between ‘issuer-requested flows’ and ‘payee-requested flows’ should be more clearly defined (the ‘issuer’ is presumably the payer’s ASPSP) and related to established SCA practices, notably ‘redirection SCA’ where the payer initiates an unauthorized payment transaction and their bank is then responsible for coordinating the capture of SCA and ‘embedded SCA’, where an authorized payment is initiated with the payer’s bank after SCA has been performed.

It should be confirmed that “Issuer-requested flows” primarily relate to redirection SCA processes (with the caveat that the “Issuer-requested flows” terminology appears deficient as banks, contrary to payees, do not ‘request’ payments but rather validate and process payment instructions received from payers). It should also be confirmed that “payee-requested flows” imply embedded SCA.

Note: We see embedded SCA as having considerable value-creation potential in terms of enhanced security, friction reduction and new use cases and services – with the added benefits that it supports both online and offline connectivity interactions but also the combination of merchant-related attributes (those requested by the merchant to finalise the sale) and bank-related attributes (client and optionally payment means attributes) which can be separated after receipt by the merchant and forwarded to PSPs for payment processing purposes. In addition, payee-requested payments usually imply the payee presenting their own payment details which, when issued as [Q]eAA, offer instant VoP - verification of payee without the need for a separate verification process. Embedded SCA can be also performed at the request of other parties, not only the payee. For example, a PSU may use the services of a multi-bank platform that provides the user with the ability to operate in one place their accounts they hold with multiple different banks. In this context, the multi-bank platform is a service provider operating on behalf of the payer. This provider may itself be certified as an Account Information Service Provider (AISP) or a Payment Information Service Provider (PISP) or it relies on the services of a 3rd party AISP or PISP. The multi-bank platform may ask the user to perform SCA to provide their consent to access account information, it may ask the user to perform SCA on a payment initiation request, set up by the user within the platform. Also, depending on availability of Electronic Bank Account Management (EBAM) API’s, it may request the user perform SCA on an account opening request for example. In a corporate context, an Enterprise Resource Planning (ERP) platform may perform a similar role. Therefore, it may be more appropriate to rename “payee-requested-flow” to “3rd party requested flow”.

We fail to understand how the distinction between ‘issuer-requested flows’ and ‘payee-requested flows’ is related to PSD2 or the more recent draft Payment Services Regulation (PSR) requirements. The discussion paper rightly mentions the 3 SCA use cases listed in article 97.1 of PSD2 but brings no justification to the view that for ‘payee-requested flows’, only the payment initiation SCA use case is permitted. We wonder where this is coming from as:
• Some of the use cases falling under article 97.1(a) are not related to payments per se – so the distinction between issuer-requested flows and payee-requested flows is irrelevant.
• Furthermore, when payments are technically requested by the payee – such as in ‘request-to-pay’ flows – they remain treated for SCA purposes as payment “initiated by the payer” under article 97.1 (b) and therefore subject to SCA.

On section 4.1 Process Control
Assuming SUA attestations are bank-issued PSU and optionally payment means attestations used in connection with SUA/SCA processes – see comment above – we fail to understand why SUA attestation issuers should have a say in defining which of the 3 SCA use cases contemplated by article 97.1 of PSD2 can be implemented. This does not conform to the current reality of banking credentials.
In the payee-requested flow, it can be assumed that all SCA/SUA created by the EUDIW controlled procedure will eventually be presented (as evidence) to the payer’s bank (via the payee), whether it relates to a payment initiation, a consent to access account information, the signing of an Electronic Mandate (in support of direct debits or variable recurring payments) or other SCA actions in support of Electronic Bank Account Management (EBAM), for example. If the payer’s bank chooses not to offer (value added, non-regulatory) API’s, for example in the case of EBAM, then the bank would simply decline to process the request.

Answer to question 1:
Answer: No, the wallet unit should not validate that a specific transaction type (e.g. payment initiation, payment mandate, account information consent) is permitted for a given SUA attestation type. However, where the attestation also identifies a payment instrument belonging to the PSU as well as their identity, the payment instrument (for example an IBAN supporting SCT-INST) must be compatible with the method of payment options specified by the relying party.

On section 4.2.1 Principle of Clarity and Unambiguity
Where an alias is included in the transaction data to represent the payment instrument (e.g. “Savings Account”) instead of e.g. the (debtor account) IBAN, our assumption is that the PISP and the payer’s ASPSP will both provided with a free of charge facility to convert this alias back to the actual account identifier (e.g. IBAN) that it represents. We suggest that this requirement is addressed in the related Attestation Rulebook or the Technical Specification 12.

On Section 4.2.3 WYSIWYS principle
As mentioned in 4.2.1, some elements of the transaction data (notably the currency code, amount and payee name) must be displayed more prominently than other elements (such as purpose of payment). The requirement for secure rendering may inadvertently restrict a wallet provider’s ability to display the other less important elements of the transaction data. Instead, perhaps the secure rendering could be limited to a confirmation prompt displaying a short statement containing the most prominent elements e.g. “Confirm payment of EUR 100.00 to XYZ Merchant”. The use of an additional confirmation prompt (perhaps also combined with the biometric or PIN capture step) would also reinforce the notion of explicit and informed consent (section 4.2.2).

In addition, it would be beneficial for the Secure Rendering Environment to produce a cryptographic attestation that evidences what was presented to the user (WYSIWYS) as well a (e.g. SHA-256) hash of the transactional data. This attestation would then be included in the data structure that is signed to produce the SCA proof.

The attestation could also include the characteristics of the secure rendering environment, such as level of assurance, for example:
• Secure software rendering would be classed as “enhanced basic”;
• A hardware backed Trusted User Interface (TUI) approach would be classed as “moderate attack potential”;
The attestation could also include the characteristics of other sensitive components such as the device integrity, level of assurance for the key storage and authentication methods.

On Section 4.3 Authentication fraud
We support the concept that the authentication code will be bound to the transactional data as well as the SUA attestation. However, it would be beneficial to clarify how the SCA/SUA proof will be invalidated whenever the user’s PID or WUA is to be revoked.

This is essential to ensure that an ASPSP does not release the payer’s funds having successfully verified the SCA/SUA proof created using a wallet unit that has previously been revoked. A wallet provider cannot remotely disable an offline wallet that remains capable of performing SCA/SUA offline in proximity use cases. Instead, the SCA/SUA proof itself must be invalidated e.g. via certificate revocation.

It must be assumed that if a wallet holder can provide evidence that they have notified their wallet provider or PID issuer that their smartphone has been stolen, any transactions relying on SCA proof subsequently created using their (revoked) wallet unit must be deemed to be unauthorized.

On Section 4.4 Fraud signals
ASPSPs must accept EUDIW SUA/SCA as per article 5f2 of eIDAS. Therefore, it can be assumed that the ASPSPs must accept the content of the SCA/SUA proof package, created by the SCA procedure controlled by the EUDIW. A valid SCA/SUA proof package provides evidence that the payer has correctly performed SCA and provided their consent to the payment. The ASPSP has no other evidence at its disposal, beyond what is included within the SCA/SUA proof package. The ASPSP has no right to access the logs or any risk signals collected by the wallet unit.
The EUDIW is a high-LOA construct which can be used to present PID and create Qualified Electronic Signatures. It is therefore entirely rational to expect that (similar to QES), the burden of proof is on the party disputing the validity of the SUA/SCA proof (e.g. the payer), not the party presenting the proof (e.g. the payer’s ASPSP) to a court of law, in all EU & EAA jurisdictions.

[tmielnicki]

Dear Stephane,
thank you for your feedback.

Let me give you the answers and comments to your text part by part.

(1)

It should be confirmed that “Issuer-requested flows” primarily relate to redirection SCA processes (with the caveat that the “Issuer-requested flows” terminology appears deficient as banks, contrary to payees, do not ‘request’ payments but rather validate and process payment instructions received from payers). It should also be confirmed that “payee-requested flows” imply embedded SCA.

The necessary details (related to intended flows) are to be specified in a rulebook/rulebooks, provided by the industry. The goal of the ARF is to provide all necessary functionality in the wallets (just) to enable all intended scenarios.

(2)

In a corporate context, an Enterprise Resource Planning (ERP) platform may perform a similar role. Therefore, it may be more appropriate to rename “payee-requested-flow” to “3rd party requested flow”

We use these terms interchangeably. Ultimately, this (terminology) is not relevant for the ARF specification.

(3)

We fail to understand how the distinction between ‘issuer-requested flows’ and ‘payee-requested flows’ is related to PSD2 or the more recent draft Payment Services Regulation (PSR) requirements.

This is may be described in detail in the SCA Attestation Rulebook or another document (up to the industry). The goal of the ARF is to provide all necessary functionality in the wallets (just) to enable all intended scenarios (and not to define them).

(4)

We fail to understand why SUA attestation issuers should have a say in defining which of the 3 SCA use cases contemplated by article 97.1 of PSD2 can be implemented.

This is to be described in detail in the SCA Attestation Rulebook or another document possibly. The schema is to be defined by the industry, not TS12. TS12 does not intend to define the schemas, just enable them.

(4)

Answer to question 1:
Answer: No, the wallet unit should not validate that a specific transaction type (e.g. payment initiation, payment mandate, account information consent) is permitted for a given SUA attestation type. However, where the attestation also identifies a payment instrument belonging to the PSU as well as their identity, the payment instrument (for example an IBAN supporting SCT-INST) must be compatible with the method of payment options specified by the relying party.

The concept that is being introduced with Topic AA and TS12 is designed based on conclusions from Large Scale Pilots and discussions within the European Digital Identity Cooperation Group. We acknowledge your opinion and it will be considered.

(5)

Where an alias is included in the transaction data to represent the payment instrument (e.g. “Savings Account”) instead of e.g. the (debtor account) IBAN, our assumption is that the PISP and the payer’s ASPSP will both provided with a free of charge facility to convert this alias back to the actual account identifier (e.g. IBAN) that it represents. We suggest that this requirement is addressed in the related Attestation Rulebook or the Technical Specification 12.

The payment instrument (i.e. any account/card identifier) will be in the attestation itself, not in the transaction data.

(6)

In addition, it would be beneficial for the Secure Rendering Environment to produce a cryptographic attestation that evidences what was presented to the user (WYSIWYS) as well a (e.g. SHA-256) hash of the transactional data. This attestation would then be included in the data structure that is signed to produce the SCA proof.

This is covered by the native mechanisms of the presentation protocols.

(7)

The attestation could also include the characteristics of the secure rendering environment, such as level of assurance, for example:
• Secure software rendering would be classed as “enhanced basic”;
• A hardware backed Trusted User Interface (TUI) approach would be classed as “moderate attack potential”;
The attestation could also include the characteristics of other sensitive components such as the device integrity, level of assurance for the key storage and authentication methods.

This is to be covered by the schema in the SCA Attestation rulebook possibly.

(8)

We support the concept that the authentication code will be bound to the transactional data as well as the SUA attestation. However, it would be beneficial to clarify how the SCA/SUA proof will be invalidated whenever the user’s PID or WUA is to be revoked.

By design (ARF), the relying party will not be in a position to check WUA status; only an issuer can check WUA. It has already been decided in the ARF how he SCA/SUA proof will be invalidated whenever the user’s PID or WUA is revoked. The requestor will have to trust the SUA attestation provider to revoke the SUA attestation if the Wallet Provider revokes the WUA.
We are considering adding to TS12 a requirement to verify WUA during issuance of SCA attestation and align the validity of the SCA Attestation with the validity of the WUA. In addition to mandate the SUA attestation provider to revoke SCA Attestation if the wallet solution provider revokes WUA.

[ETPPA]

Whilst we largely agree with the feedback of @sgmouy, we have provided our feedback by email yesterday.

[tmielnicki]

@ETPPA could you please post your feedback here in this discussion? If it is in a form of a letter, you can attach the file here too. This will ease handling your comments.

[ETPPA]

@tmielnicki please see attached.
ETPPA feedback to discussion paper Topic AA.pdf

[tmielnicki]

Dear Sirs,
here is the feedback to your comments in the file.

By design (ARF) any authentication with the wallet are performed by the presentation of an attestation. For SCA authentication, it involves transporting and processing by the wallet additional information (transactional data). Using a PID in combination with transactional data is not intended (see i.a. PID rulebook).
At the same time, signing (QES) will have its own way to use an attestation to make "signature authorisation" (and own specification of "transactional data" handling by the presentation protocol and the wallet). And use of QES functionality of the wallet for PSD2 SCA purposes is not intended. I would not to mix these things either. If you want to use QES functionality as such to sign (w/o involving "your own" transactional data handling inside the protocol and wallet), this is technically possible and you can evaluate applicability to your case.
The fallback here can be other SCA means provided by the PSP.

Regarding your comment "Our TPP community (PISPs and AISPs) intend to...", it refers more to TS12, than Topic AA and the ARF. Therefore I suggest that you provide your proposal in relation to TS12 content directly.

Regarding your comment "As financial services regulated entities with CFT & AML obligations...", these "aliases" are just informative captions for the user. Ultimately, for the wallet it is not relevant for what purpose it used and the interpretation.
If there is a need of additional "schemas" (e.g. display schemas) however, this is to be covered by the an attestation rulebook (SCA Attestation Rulebook or other possibly). (Note: such attestation rulebooks are delivered by the industry, not by the Commission).

Other comments - see the answer provided to Stephane Mouy hereabove.

[ETPPA]

@tmielnicki Many thanks for your reply. I have provided the following in the TS12 discussion as you suggested (see here), but would like to state it here as well, just for the records:

Our ETPPA community intends to take full advantage of the EUDIW to support the capture of Embedded SCA (what you refer to as payee-led) for payments, consent and e-Mandates conveyed via PSD2 APIs, such as the Berlin Group NextGenPSD2 XS2A APIs, which are the dominant ones in Europe. In effect we intend to initiate 'signed payment requests' via these APIs, with the SCA proof package created using the EUDIW which consequently must be accepted by ASPSPs (based on our reading of eIDAS article 5f2).

We therefore request that the transactional data formats that are treated as mandatory requirements for the EUDIW are closely aligned with the data structures supported by the PSD2 APIs (such as the Berlin Group JSON and ISO 20022 versions).

[tmielnicki]

Noted, see my answer in the TS12 related thread.

[cyberphone]

Since the two LSPs that developed payment support came up with entirely different solutions, maybe the discussions should start with what architecture the EU should invest in? EMV-like solutions à la NOBID and 3DS solutions à la EWC have quite different UX, security, and privacy characteristics.

I recently found out that the current idea is that each payment network (VISA, SEPA instant, etc.) is supposed to develop its own SCA solution as well as JSON Schema for the request. In a pretty advanced PoC of mine, I have universalized these elements, leading to a considerably simpler wallet. The PoC also supports receipts and account balances. Architecturally, the PoC is pretty close to NOBID.

Everything is open and free from licenses:
#388

[cyberphone]

Regarding Relying Party certificates for Merchants:

AFAIK, nobody but Apple use such and in their case it is only for stopping non-Apple customers from using their wallet. W3C/FIDO/VISA's most recent standard, Secure Payment Confirmation do not introduce RP certificates either.

There are tons of reason for not using RP certificates for payment wallets, but this belong to possible architecture discussions. There is no security and/or privacy architecture to find at this stage.

[NielsPranger]

Dear phin10,

Many thanks for drafting this document. From our side - the Dutch Payments Association, we would like to point out that we disagree with the content in chapter 3 that assumes that strong user authentication (SUA) and strong customer authentication (SCA) are the same. SUA is in essence two-factor authentication (2FA), while SCA is much more than 2FA due to the requirements set in the RTS on SCA. As a result, SUA and SCA are not equal. As described in art. 5f(2), relying parties should accept the wallet in occassions where they perform strong user authentication for online identification. Translating art. 5f(2) to payments, we believe this entails that the EUDIW should be accepted to perform the 2FA part within SCA, but not as full means to perform SCA. We've extensively described our views in a paper: https://www.betaalvereniging.nl/en/actueel/nieuws/eu-digital-identity-wallet-assessment/.

Kind regards,
Niels Pranger

[sgmouy]

Even amongst banks, this appears to be a minority opinion - to illustrate, the Sparkasse group has taken the opposite view in the Digitallabor November 2023 paper "why the acceptance of the EU digital Identity Wallet for SCA will be mandatory under eIDAS2". In addition, the Dutch Payments Association paper you refer to contains questionable assertions such as "dynamic linking [...] cannot be fulfilled by EUDIWs because they lack the functionality to meet these requirements". It's a self-serving statement. What justifies this position?

[tmielnicki]

Dear @NielsPranger ,
thank you for your feedback. Difference between SUA and SCA, in legal terms, is well known and was taken into account. However, from the wallet solution and (purely) technical perspective, the concept is the same (in general terms). Using the wallet as SCA does not obviously release financial entities from fulfilling all the remaining obligations related to SCA resulting from PSD2.
I the context of ARF, SCA is a specific case of SUA. And there will be more other cases to come (such as e-signature related). At the same time, all SUA transaction types may differ in some details (eg. how the transactional data are handled), but this is part of the intended high level concept of SUA in ARF. For SCA case, there will be two additional specific documents: SCA Attestation Rulebook and a Technical Specification. They aim to ensure that i.a. PSD2 related requirements applicable to the wallet (eg. on dynamic linking) are met.
I hope this clarifies.

[Nathall7]

Before going on technical discussions, I would highly recommend to review all ARF documents specifying use cases for SCA and in particular for payment, towards regulation compliancy (PSD2, RTS, eIDAS2, GDPR, TFEU ...).You will find herebelow a link towards personal comments for regulatory compliances for the folliwing 3 documents
A) main ARF V2.6.0 test 2.6.4 and the annex 2 High level requirements
B) HLR topic - A.2.3.20 Topic 20 - Strong User authentcaton for electronic payments
C) TS12 proposal

You will find my comments with **this shared updated link¨ to copy and paste (otherwise block) : https://share.mailo.com/?key=IzycsAKXnEvOddiddTvJtST29orSd0pqOlkLrASQzk9V3FHBJCdeyw%3D%3D

I remain at the disposal of the EU commission, DG FISMA, the two LSPs APTITUDE and new Build, for explaining or detailing further my comments.

[tmielnicki]

Dear Nathalie,
thank you for your comments and the document. We will review it and give our feedback.

[Nathall7]

Thanks. I remain at your disposal for any details in case of questions

[Nathall7]

I have also added in the TS12 discussion my pdf file directly within Github [commentaire N LAUNAY V0.1 29oct 2025 ARF .pdf) https://github.com/user-attachments/files/23386934/commentaire.N.LAUNAY.V0.1.29oct.2025.ARF.pdf