Meeting minutes
BBK clarifications
w3c/
(Ian reviews the proposal)
John: I think that works well and clears up ambiguities we noted.
… my only question is where we have a 1-1-1 relationship between browser/passkey/device, there is still a situation where the same "tuple" with multiple BBKs.
… because of different logins on the browser.
… in case of multiple profiles.
Ian: How does this approach interact with current implementation?
Darwin: Regarding profiles, there's probably a still gap where the installed browser program would mean "same bbk across profiles."
Stephen: I am hearing you can't say "1-1-1" because of profiles.
Stephen: For Chrome in particular a user with a single installation of Chrome could have 2 profiles, each of which would have a different BBK.
Stephen: An installed browser program can have multiple BBKs for a given passkey, but different installed programs are guaranteed to have different BBKs for this same passkey
Stephen: We should say in reqs do that the important statement is that a single BBK is not reused for any of (1) different installed browser programs on a device (2) different devices for the same or different installed browser program and (3) different passkeys
John: Another way of saying it: for each BBK there will be at most one installed browser program, passkey, and device.
… the important bit is that the BBK implies the tuple.
<stephen_mcgruer> A specific BBK ==> (1 browser installed program, 1 device, 1 passkey), but that relationship doesn't go in the other direction
John: the BBK enforces the tuple but the tuple does not necessarily enforce the BBK.
ACTION: John_Earnshaw to do a pull request on BBK requirements doc to (1) introduce installed browser program and (2) describe the tuple relationship more clearly.
Stephen: We are likely to want to be explicit in the spec but let's do that after the reqs document.
Roaming authenticators
SPC SHALL follow the WebAuthn flow for discovering authenticators and identifying the correct authenticator to be used.
The roaming authenticator SHALL be paired with an application or through a FIDO credential registration.
Persistent CTAP PUAT (pinUvAuthToken) SHALL be supported and the discoverable credential(s) on the roaming authenticator SHALL be cached.
SPC SHALL support providing a filtered list of eligible credentials.
SPC SHALL support cross-origin/payment credential flag (in SPC and CTAP).
----
Bjorn: There is some complexity. But one expectation is whether the device is plugged in.
… these requirements don't address situation where roaming authenticators is not plugged in then plugged in.
… there may also be slight variations among platforms.
… a roaming authenticator could be any device that acts as a roaming authenticator (e.g., the hybrid use cases as an example)
… or even a credit card that acts as a fido authenticator.
… to fully explore I assume we'd have to create a requirements document.
Ian: What does "filtered list of eligible credentials" refer to?
Bjorn? There might be different credentials that could be used for different purposes.
Bjorn: There might be different credentials that could be used for different purposes.
Ian: That feels like a new functionality (for any authenticator)
Ian: "SHALL be paired with an application or through a FIDO credential registration."
Bjorn: The credential on the roaming authenticator is discovered; you have to onboard the credential from the roaming authenticator.
Currency code topic
WICG/
Sid: ISO 24165 - Digital token identifier (DTI) appears be the future standard for digital currencies from ISO.
https://
Sid: Unlike the 3-letter ISO 4217 codes, DTIs use 9-letter alphanumeric codes (e.g. 4H95J0R2X for Bitcoin, L6GTZC9G4 for Ripple, and ZNWVNRMHK for USDC Eth). I'm not sure whether these registrations are official, or how was the community interest towards adoption of this standard (given there are so many alternative standards in crypto community), but this should give us some direction.
Sid: I've not seen evidence that these are used publicly.
Sid: until there's public demand (from wallets) e.g., in Payment Request, we can put this topic on the back burner
Reminder of ECommerce/AI workshop (8-9 September in Zurich)
September 8 and 9 2026 in Zurich.
(Ian gives background on workshop.)
Ian: The call for participation will be sent soon. If you want to help organize the agenda via the program committee, please let me know.
Ian: I anticipate that one outcome of the Workshop may be suggested work items for various SDOS and WGs, including this one.
Upcoming schedule
4 June
No meeting on 18 June
Ian: I propose 1-day WG meeting on Thursday at TPAC
… and 2-day for IG on M/T
<stephen_mcgruer> No strong reaction, unfortunately in my head far too far ahead of TPAC to know what agenda topics would be :D