Meeting minutes
TPAC follow-up
Ian: I drafted a TPAC Recap that is still long but easier reading than the full minutes of the week. I expect to turn into a (much shorter) blog post.
<Roger> Ian This is the payment solution that handles QR Payment you asked me during TPAC https://
Ian: Any other big takeaways from TPAC?
stephen_mcgruer: From Chrome payments perspective, this was the best TPAC we've been to...very collaborative and felt like lots of momentum and good ideas. I am excited by the momentum. Glad to see new people as well!
Gustavo: +1. I was an EMVCo meeting the following week, and TPAC helped us ramp up for that as well
SPC Issues
Reducing the risk of double step-up
Ian: There are two leading proposals on the table:
- Proposal involving multiple BBKs and an allow list
- Proposal using userVerification=discouraged (hint)
Ian: Which approach to take?
stephen_mcgruer: The userVerification is likely easier to implement and reason about, but the main question is to understand the impact on users. I think someone needs to take the action to identify the delta for users.
… or developers
Henna: We are leaning userVerification approach, which we think is much cleaner. But we likely need to look more closely at implications.
ACTION: Ian to reach out to Tomasz to try to work on the user journey / developer impact of one proposal v the other.
BBK Feature Detection
stephen_mcgruer: This one is "just likely to happen"; I'm not hearing concerns so I think we will just figure out some API shape for this.
… we'll still need to do formal security/privacy review, but so far looks ok.
Ian: Any input you need?
stephen_mcgruer: Not today.
Ian: Is everyone's expectation that this is a boolean?
stephen_mcgruer: We will probably support an enumeration (e.g., hardware, software, none)
… to allow for expansion.
ACTION: stephen_mcgruer to look at API changes to support BBK feature detection.
SPC MVP
Henna shared Visa's list of features for SPC MVP with prioritization.
| Short name | Requirement | Visa priority (1 is highest) | Related issues | Next steps |
|---|---|---|---|---|
| BBK Feature detection | Eligibility checks for BBK supported on browser – add new reason codes. Enhance ‘https://w3c.github.io/secure-payment-confirmation/#dom-paymentrequest-securepaymentconfirmationavailability’ | 1 | Issue 290, Issue 315 | Awaiting Chrome response on feasibility |
| Honor UV=Discouraged | Google Password Manager (GMP) to honor userVerification=discouraged |
1 | Issue 287, Issue 315, Issue 317 | Shouldn’t this be assigned to the Android / GPM team? Hence maintained priority 1. |
| SPC with and without passkeys | SPC should work with passkey authentication, (2FA – BBK + Passkey inheritance / knowledge). The RP gets back two signatures to verify – one with the BBK and one with the passkey. Only confirmation screen (1FA - BBK) (without user verification) by setting UV flag to discouraged. The RP gets back two signatures – one signed by the BBK and one signed by the passkey however with no UV. |
2 | Related to discussion around SPC being supported in regulated (2FA) and non-regulated (1FA) markets | |
| Avoid double step-up | Today when RP authenticates the user on a new device where a passkey has synced, after passkey authentication – the new BBK is sent to the RP and the RP has no knowledge of this BBK hence will do an extra ID&V. To avoid this double authentication issue – an explicit allow list for BBK’s could be used where if the BBK is not in the allow list for an associated passkey, the browser sets the UV = discouraged flag which suppresses the passkey authentication, such that the RP can then go ahead and do a cardholder ID&V. |
3 | Issue 287, Issue 315 | |
| SPC immediate mediation for 1p | SPC should support WebAuthn preferImmediatelyAvailable (immediate mediation) when the relying party calls SPC. This would remove the need for the fallback UX in that context. |
4 | Track immediate mediation progress in WebAuthn WG | |
| Support more use cases | Structured dataset to support new payment methods and options – such as recurring, agentic etc. | No priority provided | Issue 185, Issue 313 | Review Apple dataset for recurring |
Henna notes:
- "Honor UV=Discouraged" also helps with both "SPC with and without passkeys" and "Avoid double step-up"
- No priority yet on "Support more use cases" but we can continue to discuss in parallel.
<stephen_mcgruer> [As always, I am required to point out that UV=discouraged is just a hint]
Henna: Any initial feedback on this list?
stephen_mcgruer: The main question for me is whether UV=discouraged will result in the expected UX. E.g., on Windows there will always be authentication. We can make this work on MacOS. I need to find out on Android.
… there's a related (implementation) question -- what authenticator in practice we use? Today we (Chrome) are spread across three authenticators.
Henna: We just need to check on how will UV=discouraged be handled. On the Windows side, I thought there was a conversation about why Windows Hello was being used instead of GPM.
stephen_mcgruer: Good open question.
… three of the requests hinge on UV=discouraged so that's the big question for me.
ACTION: Ian to publish this table in a way to get group input (including other prioritizations)
Regulatory requirements related to authentication means
(In the link above see "The authentication_factors array MUST contain at least two different objects representing authentication categories. ")
Jean-Luc: I spoke with the author of the specification and, for compliance with regulation, the financial institution needs to know about authentication factors
… this is an EU requirement that's been included in the technical specification
… if, for example, we want to use passkeys for recurring authentications ... I would no longer have the required information
stephen_mcgruer: From the Web perspective, neither WebAuthn or DC API require attestation or give you attestation by default. It's up to the underlying wallet or passkey provider.
… we know in the EU that wallets will be forced to provide attestation that provides the type of verification method(s)
… technically WebAuthn supports attestation. Is this a world where passkey providers will start providing attestation?
… the big difference is that for passkeys it's "bring your own passkey provider" but for EUDI Wallets, only certified wallets will work.
Ian: I am hearing "passkey providers" don't typically provide attestation today but (at least some) could and it will be required in some (EU) contexts.
stephen_mcgruer: Some passkey providers don't provide attestation today nor do they expect to.
Isaiah: Google and Apple have said they won't provide attestation. Windows can, in some contexts. All the other credential providers cannot provide attestation.
… attestation is scoped to enterprise contexts.
Jean-Luc: The wallet provider in EU will provide attestation within the payment credential. But if we don't find an equivalent for passkeys or SPC, we won't be able to provide synergies for use cases like recurring.
… so in EU people will always go through a wallet.
stephen_mcgruer: I agree with JL that it seems like passkeys in their current direction are not likely to be compliant.
Isaiah: If WebAuthn doesn't support it, it will never be available due to how things work
Jean-Luc: There's a related challenge...
https://
… currently there's no way for an RP to know that two private keys are stored in the same device (e.g., for two credential use cases like age verification credential and payment creation).
… I was wondering whether the BBK might be useful for that.
Tomasso: Or DBSC
Jean-Luc: BBK could be used to sign data from DC API to provide proof that two blobs on the same device
PR API and digital payment credentials
Ian: More to come!
Facilitated payment links
Ian: The extended call for consensus to take up the Faciliated Payment Links in HTML proposal ended with some support
… we then discussed during TPAC as well as other possible approaches
… as a result, I requested that the Chrome Team do an analysis of the options for us to discuss before taking up formally. Stephen, can you confirm that's your understanding as well?
stephen_mcgruer: Ack
Next meeting
18 December