FIDO for User Sole Contol in the EUDI Wallet

[Anti-Myon]

Issue

The current ARF specification prescribes a framework of requirements and mechanisms for implementing Wallet Trust Evidence (WTE), essentially indicating the need for client device attestation, which is yet to be fully concretized. Additionally, Article 5a of the eIDAS 2.0 regulation clearly mandates that the EUDIW must offer a high Level of Assurance(LoA) for identification and authentication, and must enable the user to interact with the wallet under their sole control.

We propose leveraging a FIDO authenticator kernel and the FIDO attestation framework to cover for those requirements. The attached discussion paper demonstrates how a FIDO kernel can be integrated into the high-level EUDIW architecture and how the FIDO attestation framework can transparently address the level of user sole control provided by an EUDIW instantiation on a specific client device. While a certified hardware key store effectively protects against the theft of user keys, user sole control additionally requires that trusted user interfaces enable users to reliably control the purpose for which their hardware-protected keys are used. Given that RPs' sensitive services heavily rely on protected confirmations, such as Strong Customer Authentication (SCA) with dynamic linking for payments (as required by PSD2), it is crucial that an EUDIW instantiation can evidence its WTE regardless of whether the specific client device is infected with malware. FIDO provides this type of attestation, making it a crucial component of the EUDIW toolbox.

Dependencies

We recommend integrating FIDO in a revised ARF as well as in the Implementing Acts.

Cf. submitted opinion paper https://apc.ti.bfh.ch/img/FIDO_EUDIW_wiley.pdf doi: https://doi.org/10.22541/au.172456735.58663962/v1

[digeorgi]

Thank your for your comments on opinion paper. We will certainly take the use of FIDO Passkeys into consideration for the EUDI Wallet ecosystem in ARF v1.5.0 and will refer to your paper during this process.

[Alpha-Hexa]

Dear Georgiou, Sebastian and Paolo,

Hope you are doing well since our meeting in Luxemburg and our short email exchanges. Many thanks also for your very encouraging response Georgiou regarding our paper on User Sole Control.

In the interest of both groups, the ARF expert team and the authors of the paper (in cc:), I am convinced that it could be instrumental to have a short Teams call, just between our groups, to briefly exchange and sync on the potential added value that FIDO standards could bring to the EUDI Wallet. We irrespectively remain committed towards best possibly leveraging existing standards towards driving the user sole control obligation and the closely related wallet trust evidence topic into a sensible and eventually conclusive direction.

Many thanks in advance for considering our proposal and getting back to us with 1 or 2 time slot suggestions for a Teams call, in case of interest. The first 3 weeks of November could be ideal for such a call.

Kindest regards, Alain Hiltgen.

From: Dimitrios Georgiou @.> Sent: Wednesday, October 16, 2024 11:08 AM To: eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework @.> Cc: Hiltgen, Alain @.>; Manual @.> Subject: [External] Re: [eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework] FIDO for User Sole Contol in the EUDI Wallet (Issue #302)

Thank your for your comments on opinion paper. We will certainly take the use of FIDO Passkeys into consideration for the EUDI Wallet ecosystem in ARF v1.5.0 and will refer to your paper during this process.

- Reply to this email directly, view it on GitHubhttps://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/302#issuecomment-2416185456, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BKW33KZPN7LN7JOB5AMGCKLZ3YUIZAVCNFSM6AAAAABMX63UMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWGE4DKNBVGY. You are receiving this because you are subscribed to this thread.Message ID: @.***>

E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, potential manipulation of contents and/or sender's address, incorrect recipient (misdirection), viruses etc. Based on previous e-mail correspondence with you and/or an agreement reached with you, UBS considers itself authorized to contact you via e-mail. UBS assumes no responsibility for any loss or damage resulting from the use of e-mails. The recipient is aware of and accepts the inherent risks of using e-mails, in particular the risk that the banking relationship and confidential information relating thereto are disclosed to third parties. UBS reserves the right to retain and monitor all messages. Messages are protected and accessed only in legally justified cases. For information on how UBS uses and discloses personal data, how long we retain it, how we keep it secure and your data protection rights, please see our Privacy Notice http://www.ubs.com/privacy-statement

[cyberphone]

@Alpha-Hexa Although FIDO is great, the FIDO security/privacy model presumes that the Issuer=RP which does not match one-to-many identity wallets. For payments FIDO could work as proven by SPC (https://www.w3.org/TR/secure-payment-confirmation/).

However, the lack of metadata support requires users to (continue to) give their card number (with PII and all!) to Merchants which is one of the reasons SPC never seems to get traction. Compared to Apple Pay, SPC totally sucks. In addition, Apple never bothered supporting SPC.

You may be interested in looking into a wallet spec. using FIDO for payment authorizations: https://fido-web-pay.github.io/ Since it requires "buyin" by Google and Apple, it of course goes absolutely nowhere :(

A related issue which nobody seems concerned with, is how to integrate payment wallet support in banks. https://github.com/digitallabor-berlin/eudiw-sca/blob/main/openbanking-r2s.md depends on the Berlin Group's "Signed Payment Request" framework. Personally, I don't think this will work because it is costly, slow, and inflexible. FWIW, I'm currently in the early phases of creating another integration solution, intended to be usable for any wallet solution, including proprietary wallet schemes like https://epicompany.eu.

URL: https://github.com/cyberphone/open-banking-2.0/tree/main?tab=readme-ov-file#open-banking-20

It is not clear what the EWC (https://github.com/EWC-consortium) folks are planning with respect to the interface to banks, since their payment-related specifications still are kept under wrappers...

What is clear though is that FIDO/WebAuthn represents an alternative to identity wallets. Getting away from phishing and passwords is "good enough" for many private sector applications including social media and ecommerce.

@digeorgi @paolo-de-rosa

[Anti-Myon]

@Alpha-Hexa Although FIDO is great, the FIDO security/privacy model presumes that the Issuer=RP which does not match one-to-many identity wallets. For payments FIDO could work as proven by SPC (https://www.w3.org/TR/secure-payment-confirmation/).

Please note that we are not referring to SPC, which is implemented in the browser but to the FIDO Protected Confirmation extension for SCA on an authenticator https://github.com/w3c/webauthn/pull/2020. FIDO’s 1to1 authentication keys are essential towards implementing unlinkability for SCA as mandated by eIDAS.

However, the lack of metadata support requires users to (continue to) give their card number (with PII and all!) to Merchants which is one of the reasons SPC never seems to get traction. Compared to Apple Pay, SPC totally sucks. In addition, Apple never bothered supporting SPC.

Note, that we do not want to replace any EUDI Wallet selective disclosure solution. However, a Wallet could easily leverage a FIDO authenticator for storing critical keys such as authentication keys required to access sensitive banking or health data. Moreover, the FIDO meta server could easily serve covering for the Wallet Trust Evidence need towards relying parties.

You may be interested in looking into a wallet spec. using FIDO for payment authorizations: https://fido-web-pay.github.io/ Since it requires "buyin" by Google and Apple, it of course goes absolutely nowhere :(

We are not referring to SPC. FIDO extensions - if implemented - are totally independent and agnostic of the OS.

A related issue which nobody seems concerned with, is how to integrate payment wallet support in banks. https://github.com/digitallabor-berlin/eudiw-sca/blob/main/openbanking-r2s.md depends on the Berlin Group's "Signed Payment Request" framework. Personally, I don't think this will work because it is costly, slow, and inflexible. FWIW, I'm currently in the early phases of creating another integration solution, intended to be usable for any wallet solution, including proprietary wallet schemes like https://epicompany.eu.

URL: https://github.com/cyberphone/open-banking-2.0/tree/main?tab=readme-ov-file#open-banking-20

FIDO Protected Confirmation is perfectly suited to address the PSD2 SCA, i.e., authentication and authentication with linking requirements. Many banks are looking into FIDO for SCA.

It is not clear what the EWC (https://github.com/EWC-consortium) folks are planning with respect to the interface to banks, since their payment-related specifications still are kept under wrappers...

We try to convince also the LSPs to consider leveraging FIDO authenticators for the following key security and trust reasons:

• Trusted User Interfaces for SCA
• HW bound segregate Key Store in TEE
• eIDAS certification for LoA substantial and higher
• Flexible Attestation / Wallet Trust Evidence towards RPs
• Cross Device Access via CTAP

What is clear though is that FIDO/WebAuthn represents an alternative to identity wallets. Getting away from phishing and passwords is "good enough" for many private sector applications including social media and ecommerce.

@digeorgi @paolo-de-rosa

[cyberphone]

Without going too deep into this, what's the point of a wallet that requires a specific key for each RP/domain?

Existing, very popular wallets (like Sweden's BankId), permit logging in to hundreds (sometimes thousands) of services with a single credential and key.

[Anti-Myon]

Without going too deep into this, what's the point of a wallet that requires a specific key for each RP/domain?

Existing, very popular wallets (like Sweden's BankId), permit logging in to hundreds (sometimes thousands) of services with a single credential and key.

You achieve unlinkability, reducing the privacy risk posed by linkability, which increases the likelihood that anonymous or pseudonymous data could be traced back to specific individuals.

[cyberphone]

You achieve unlinkability, reducing the privacy risk posed by linkability, which increases the likelihood that anonymous or pseudonymous data could be traced back to specific individuals.

Yes, but to achieve this you don't need a wallet, FIDO/WebAuthn as it stands suffice. No additional software needed.

Regarding unlinkability, it is good keeping in mind that practically all services (of any importance), require the user's email address and/or mobile phone number. Since these represent GUIDs, it does (in reality) not matter what measures the EUIDW take to achieve unlinkability since they are effectively undermined by how things work today.

If unlinkability indeed is a major requirement, we need to come up with a way of performing secure, anonymous, bi-directional, per party, communication that works similar to email and SMS. I'm not aware of any serious activity trying to accomplish something along these lines. Depending on specific anonymization services is a possibility, but it seems to just move the problem rather than solving it. Even IP addresses have been used for tracking down criminals.

[cyberphone]

@Anti-Myon The more I think of unlinkability, FIDO/WebAuthn would be an excellent solution; not for a wallet, but for a messaging client!

Spurred by this discussion I posted the following rant on LinkedIn: https://www.linkedin.com/posts/andersrundgren_note-this-posting-is-not-specifically-about-activity-7255842581991882752-6EH7/