Meeting minutes
State of Platform Authenticators for SPC in Chrome
smcgruer_[EST]: A "platform authenticator" is one that is "generally available on the literal same device"
… historically it was the one built into the device, but now there are third party options
smcgruer_[EST]: On Windows, for example, there are three types of platform authenticators: Windows Hello (provided by MS), Google Password Manager (only available for Chrome on Windows) and 3p passkey providers
smcgruer_[EST]: On MacOS you have iCloud Keychain (from Apple; default platform authenticator) (2) chrome internal profile credential store (legacy) (3) Google password manager (4) 3p passkey providers via ASPasskeyCredentialRequest
smcgruer_[EST]: SPC uses the internal profile credential store
smcgruer_[EST]: On Android, there are only passkey provider apps: Google Password Manager (often but not always default; cf Samsung phones), 1password, bit warden, lastpass, etc.
smcgruer_[EST]: On iOS (1) iCloud keychain (2) passkey providers via ASPasskeyCredentialRequest
smcgruer_[EST]: On Linux and ChromeOS, Google Password Manager
smcgruer_[EST]: Authenticator capabilities relevant to SPC:
… synched passkeys
… ability to create a silent list of credentials. This enables the choice between authentication UX and fallback UX. This is one of the main APIs we thought would be a thing for other situations as well (e.g., immediate mediation). But in practice, the OS has the list and Chrome does not have access to ti.
… ability to store the third party payment bit (CTAP)
… but platform authenticators don't follow the CTAP spec necessarily, so they don't have to support that bit (and many don't yet)
… in the absence of the third-party bit, Chrome stores it instead. So the info is not available through synching or across browsers on the same device.
(Stephen walks through table of which authenticators are used in practice with SPC today)
smcgruer_[EST]: On Windows, it's not clear that we'll be able to access 3p passkey provider credentials through the list-credentials API
Rene: The API is in the Windows nightly; but there is someone from Chrome working on this and you do have access to list the credentials.
smcgruer_[EST]: On MacOS, chrome uses legacy credential store. This store does not and won't sync credentials.
… so passkeys on macOS are not syncable.
… 3p bit not stored (but not needed in this case)
… list-credential API available on MacOS but not yet used by Chrome's SPC implementation
smcgruer_[EST]: On Android, we use Google Password Manager (called directly, not through the credential manager API, because doing it this way give us a list-credential API)
… the credential management API does not enable a browser to get a list silently.
[Stephen looks at possible future changes for platform authenticators used by Chrome for SPC]
smcgruer_[EST]: Using Windows Hello list-credentials API would allow us to use webauthn credentials that don't have the payment bit set. This seems do-able and valuable.
smcgruer_[EST]: We could also store the 3p payment bit in windows hello, which would allow cross-browser usage on same device (or also synching if the bit is also synched)
… question of impact on 3p passkey providers, who may or may not store the bit.
… we could take a fallback approach to test if 3p bit storable and if so, store it in that authenticator
smcgruer_[EST]: Support google password manager.
smcgruer_[EST]: Moving to MacOS, we could use internal profile credential store. But most passkeys are not stored there today
… most passkeys are in GPM or iCloud keychain
… we probably can support GPM but haven't done the analysis yet
… for iCloud keychain, there is no 3p payment bit. It does support listing credentials but not silently (there's a prompt)
smcgruer_[EST]: there's a general question of support for 3p passkey providers.
(Stephen walks through 3p scenarios and changes)
… on Android, could use CredMan but would lose list-credential API
Bjorn: Yubico would like SPC support for roaming authenticators.
Ian: Any new news from WebAuthn space?
Ian: What would be good triggers to realize any of the future directions?
smcgruer_[EST]: If we think about capabilities, we need to understand how important the 1p usage of a non-payment credential is?
… on Windows the 3p bit is browser bound and we could use Windows Hello
… so those are the two use cases that seem quickest to unlock
rene: For Windows, it's complicated. The SPC bit exists for the internal Windows Hello authenticator but it doesn't exist yet as an option for 3p providers.
… so might need both internal and external support for that bit.
Ian: Do you know when you are dealing (as Chrome) with a 3p provider? Or is that opaque by design?
Rene: My understanding is you can know, but not clear to what extent
Avoid double step-up
w3c/
smcgruer_[EST]: Recall that with BBKs, when the caller first sees a BBK (after FIDO authentication), there may be a second step-up to trust the new BBK.
… some providers expressed concern about the double setp-up
… we have a proposal that reduces double step-up, but it's a bit complex
… at a high level, the caller always gets back a BBK, and when first seen the BBK is "not yet trusted" but "can be trusted in the future"
… the caller passes in a list of trusted BBKs
… the caller also passes in the most recent "not yet trusted BBK" and if the user successfully authenticates, it becomes associated (in the browser) with the passkey
Rene: Is there anything with user consent that is protecting the website of the RP from creating those eventually trustworthy BBKs?
smcgruer_[EST]: You, you get different potential BBKs until you go through an SPC authentication.
Rene: If there's some form of user consent dialog, it might be ok.
smcgruer_[EST]: Agreed.
Fahad: What would be passed as input for the BBK?
Slobodan: Public keys
Fahad: Suppose there's a payment service provider calling SPC, so chrome shows sheet and "confirm" and chrome returns a new bbk.
… suppose the merchant includes BBK (without doing ID&V) in next call
… does that cause the BBK to be added to the trust list?
smcgruer_[EST]: What makes a passkey trusted in the first place? Our understanding in the flow you just described is that the merchant need to ask some other party to step-up
Fahad: I understand the actual RP can say "we don't trust this BBK"
smcgruer_[EST]: the RP will not pass in the BBK because it's not trusted by the RP
… what possibly should happen is that even if a credential has a BBK, it might need to be overwritten
slobodan: If we allows a BBK to be overwritten, malicious merchants could blow them away arbitrarily.
smcgruer_[EST]: You can't cause the BBK to be trusted.
smcgruer_[EST]: The problem is you can't replace the poisoned BBK
smcgruer_[EST]: You could fix it later?
… to the issuer it looks like a new unbound BBK
Ryan: Does this change the response for "continue with other verification"?
smcgruer_[EST]: Yes, it would be a breaking change .... this is theoretical
Ryan: We are interested in this, even if complex.
… this would be worthwhile.
Henna: The complexity of the proposal for avoiding double step-up is a source of concern, but it's worth exploring.
… we need to evaluate this against the cost and frequency of double step-ups
Ian: Next steps?
smcgruer_[EST]: We'll try to fix the issue raised today "the poisoning attack"
Issues to close
Propose to close issue 56.
Propose to close issue 98 (fallback UX) since progress has been made. If immediate mediation takes hold in WebAuthn we can revisit the topic including the need for any fallback UX.
Propose to close issue 174 now that we have added BBKs to SPC.
Propose to close issue 154 since cross-origin feature only used in SPC.
-------
Ian: Propose to close issue 56 due to inactivity
Tomasz: Ok to close.
-----
Propose to close issue 98
----
Propose to close issue 174
----
Propose to close issue 154
=====
next meeting
31 July
TPAC registration
Registration for TPAC 2025 is now open. The WPWG will meet 10-11 November. WPSIG will meet 13 November.