Meeting minutes
Chrome updates
smcgruer_[EST]: Google password manager passwords -> passkeys
… NickTR asked about this
… another topic was UVI and UVM
… UVI no longer a thing
… UVM is "user verification method"
… it is implemented in some authenticators but generally discouraged by WebAuthn and implementations may be broken
… but FIDO is hearing that regulations require reporting of what authentication method was used.
… so there may be some movement to expose UVM again
Rolf: If you combine UVI and UVM, it WOULD be different (you could verify it is the same fingerprint as used before)
nick_s: I'd have to confirm but I think we'd consider exposing UVM a privacy risk
… we might be able to expose whether a value had changed (e.g., since signup)
Rolf: I agree it adds a bit of entropy, but if there are three types of authentication around the world, it might not add a lot of entropy
smcgruer_[EST]: The fact that some people may not use fingerprints (temporarily or permanently) was one reason to discourage people from saying "I only use fingerprints"
smcgruer_[EST]: Now some perspectives (personally) on SPC
… work is continuing on UX
… I hope to have eng working on implementing in Q2
… sooner rather than later: prototype fallback UX (e.g., transaction UX always appears; with clearer outcome results)
… will make it easier to distinguish three outcomes: success, user does not want to continue, cancel transaction
… updated UX as well
… things for the WG to drive:
* Device binding
* signature even if no webauthn credential present
* recurring paymetns
* hybrid/remote authenticators
smcgruer_[EST]: People are looking for partners who want device binding who want to ship something.
smcgruer_[EST]: There is a lot the WG could be doing on recurring payments; e.g., working with EMVCo on how they represent that and could we translate to SPC
… could it be aligned with how other *Pay present information
… that might be useful for PR API more broadly.
… regarding remote authenticators; we could work on how to check whether (remote) credentials are available.
smcgruer_[EST]: Things that we don't expect to do soon: android native SPC; non-payment use cases
… that's more of a webauthn thing
Ian: What is relationship to this in webauthn:
Rolf: It's explicitly for non-payments use cases (e.gl, share health data)
… there's a need for trusted UI going forward.
… regulators want protection against issues like MITM or injection attacks
… there is a push for more "sign what you see" secure UX
… we heard general interest from Chrome
… have not heard back from other browser vendors yet
… this is an ongoing discussion
Ian: Why is this different from what SPC is doing?
Rolf: Not intended for use with non-RPs
… also this is not currently designed for structured data
… also SPC as designed today is browser-based. There is a need for a more secure / trusted UI
… in tx proposal, the display could be done by the authenticator.
… security keys could display information
Tomasz: Regarding this WebAuthn extension - in the assertion is there a hash of the info that was displayed to the user?
Tomasz: (I have not read the pull request yet)
Rolf: Yes. There are two places that could be signed: collected client data (the authenticator signs "blindly")
… there's a second place is the extension which is part of the "to be signed" object.
Rolf: ...SPC only supports the first; the extension supports both
… if the authenticator has shown the information, it is included in the "to be signed" object; that's a different kind of security guarantee. It is an attested entity in some cases
smcgruer_[EST]: SPC does not support that today but it could pass the data to the authenticator.
[Discussion of what you get without attestation]
Rolf: You still get attestations in some cases; and that's a higher value
smcgruer_[EST]: Privacy sandbox update
… regarding 3p cookie deprecation
… current timeline is 100% of third-party cookie deprecation during Q3
… so far we have heard limited impact on payments folks
… if you are impacted, time is running out; please contact us
smcgruer_[EST]: With passkeys and pluggable passkey providers there is a reality where passkey providers don't do fresh authentication.
… we need to keep an eye on this for SPC.
… there's a question on how that would be represented.
… there is another WebAuthn issue on user verification caching
Doug: Got a timeline on DBSC availability in Chrome?
smcgruer_[EST]: No idea.
ACTION: Ian to dig up info on DBSC timeline from authors
<Rolf> User Verification Caching extension, see w3c/
Jean-Luc: Question related to earlier topic of passkeys and SPC
… CTAP 2.2 will support 3p bit. Does that have an impact on SPC and synchronization in the cloud?
<JeanLuc> https://
smcgruer_[EST]: I'm not familiar with passkeys being tied to specific CTAP versions
… platform authenticators can already support 3p bit and sync passkeys (that's the case with Android)
… I don't think the CTAP version really matters; it's really for roaming authenticators
IJ: What does the API need?
smcgruer_[EST]: "Check if credential is available right now" but that doesn't work for roaming authenticators; spec needs a way to deal with "not available right now but might be"
… somehow we need to say "if you don't know if the key is available right now; we should still show tx dialog"
… and add a note that the dialog must allow the user to use a security key.
Rolf: I'd be happy look into that.
ACTION: Ian to reach out to Rolf to discuss spec support for roaming authenticators
Payment Request Updates
Ian: We are planning to publish PR API as a series of CR documents so that we can add back addresses; see the plan. I expect that the next thing the Working Group will see, after the Editors have prepared the documents, is a call for consensus to publish the Candidate Recs.
TPAC 2024
23-27 September in Anaheim, California
IJ: any conflicts people are aware of?
IJ: Default will be M/T for WPWG unless we hear of conflicts.
Next meeting
28 March
No meeting 11 April