Meeting minutes
Leveraging FIDO User Verification Index (UVI) as a Cross-Browser PSD2 "Possession Factor" for Passkeys
w3c/
Jean-Luc: Can we use the UVI of WebAuthn to add a trust signal to passkeys?
Jean-Luc: There are three European drivers in my view:
* eIDAS
* PSD2/SCA
* PSD3
Jean-Luc: SCA is not just for payments, but other payment-related actions like releasing sensitive information or accessing an account
… eIDAS is for mid-2027, and the final ARF in Autumn 2026
… and PSD3 will include additional guidance against fraud protection to demonstrate that a transaction was properly authenticated
… PSD3 also emphasizes accessibility and inclusion
Jean-Luc: EBA clarified in 2019 what constitutes a possession factor:
* Unique
* Bound to device
* Securely stored
* Involved dynamic validation
Jean-Luc: So synched passkeys appear to comply (and what we've worked on BBKs in SPC)
… there are also broader fraud and regulatory requirements for banks:
* account takeover and phishing defense
* Friendly fraud protection
* AML and KYC
* Identification and authentication method requirements
* Fraud monitoring and audit logs
Jean-Luc: There will likely be a need to know what authentication mechanism was used (and whether complies with internal policies)
(On FIDO UVI)
Jean-Luc: The WebAuthn spec indicated that UVI was introduced for the detection and prevention of "friendly fraud"
… with each biometric (e.g., fingerprint) there is a unique UVI
… the UVI is a combination of biometric data + unique id + non-resettable counter
Jean-Luc: The UVI is signed (in the same way that SPC data is signed). It becomes interesting for payments because it looks like a device-binding signal in the assertion
Gerhard: The definition speaks strongly to biometric. Is UVI only applied in case of biometric?
Jean-Luc: I don't know
Jean-Luc: UVI was an extension in WebAuthn L1 but was removed in L2.
<smcgruer_[EST]> w3c/
Jean-Luc: My proposal is to reintroduce into L3
… could be introduced into SPC as a default extension.
… could complement BBK
… could complement digital wallet
Ian: A path could be:
* Figure out if useful to payments through discussion in this group
* If so, approach WebAuthn WG to see if they will reintegrate.
* If they don't want to, see if they object to adding to SPC
(Jean-Luc summarizes how UVI looks to fulfill the various EU regulation requirements about device binding, dynamic linking, 2FA, etc.)
Gerhard: The WebAuthn WG removed it in L2. Do we know why?
Henna: Yes, good question. Do we have any implementations of this from L1 days?
smcgruer_[EST]: See WebAuthn issue 1386 (where more extensions were removed). The main reason was "never implemented by anyone."
… I would strongly suspect that since this arguably equivalent to device-binding, you'd run into the same resistance encountered with DPK and SPK
Jean-Luc: With respect to PSD3, there are upcoming new requirements.
… independence of SCA factors, non-repudiation, privacy protection, etc.
Jean-Luc: So the reintroduction is to help address requirements that are coming up.
… paths: (1) reintroduce in WebAuthn L3 (2) extension on by default in SPC
Ian: Should we enhance BBKs with other cool features you see enabled by UVI (that are not already part of BBKs)?
Jean-Luc: May be useful as a complement to BBK to get more broad adoption
… from my POV it might be interesting for banks to get more signals
smcgruer_[EST]: I would love it if authenticators adopted features to meet payments regulatory requirements. Maybe we need to lean more on WebAuthn as an industry.
Henna: It's worth a shot to approach the WebAuthn Wg.
… make that case that this is needed for any payment authentication
Ian: How do you see the requirements articulated here intersecting with trust signals work?
Henna: Can some of these requirements be added on top of BBK?
Henna: I don't see the requirements identified by Jean-Luc as intersecting with the trust signals work
smcgruer_[EST]: We (Chrome) are interested and willing to figure out what extra data could be provided via BBKs. E.g., the question has been whether to attest the BBKs.
… the question of "which method of authentication" may not be data available to the browser. I think platform authenticators don't provide this info (and I don't know about via CTAP)
… so I don't know that the browser has that info.
Henna: We could see if UVI/UVM requests could be made in a high-assurance login context instead of a payment context.
… eIDAS says there needs to be pseudonymous authentication and passkeys are the way to do it.
… do we need this level of granularity for that login?
… so could we make this a story about some login use cases as well
Jean-Luc: +1 to Henna's point
<smcgruer_[EST]> +1 to Henna as well
Ian: We have a joint meeting planned at TPAC. Should we do this in person there or sooner?
Henna: Sooner
… maybe positioning is "high assurance login" at this point to get full attention
… and map to eIDAS
<smcgruer_[EST]> +1 again to Henna for both timing + the framing
ACTION: Jean-Luc to revise presentation to focus on high assurance login use case driven by eIDAS, to use as basis of a joint meeting between WPWG and WebAuthn
Non-normative UX guidelines for implementors and integrators
smcgruer_[EST]: We've started work on UX improvements on desktop (in addition to mobile)
… we see value in providing guidelines related to UX. These guidelines would be non-normative UX guidelines.
… we'd like community-driven good practices
Bjorn: It will be hard to give UX feedback if I don't have anything to share internally.
smcgruer_[EST]: We're working on non-branded mockups
smcgruer_[EST]: And anyone can use the payment entity logo demo tool to create your own mockups as an FYI
Ian: What is timeframe for non-branded mockups?
ACTION: smcgruer_[EST] to share mockups without specific logos at an upcoming meeting
Ian: Any editor volunteers for a UX guidelines doc? (No hands go up)
Ian: Can we make this just a markdown doc in the SPC repo?
<smcgruer_[EST]> +1 to markdown doc
ACTION: smcgruer_[EST] to move v1 of their text into a markdown doc in the repo
Chartering
Ian: W3C has announced that the WPWG charter was approved and the group extended for 2 years. Congrats to the group! It's going to be necessary to rejoin the group (due to increased scope). Please let your AC Reps know. Our new charter allows us to take up the Facilitated Payment Link Type in HTML proposal. And, coincidentally, the TAG has just request for conversation on payment link type in HTML requested a conversation about this proposal, which means it may become a more active discussion topic on our agenda.
Next meeting
14 August