Meeting minutes
SPC updates
Review of pull request 286 and BBK requirements
Henna: We've reviewed the pull request 286 and the BBK requirements to see if they are met by the BBK functionality.
… we have some general comments and some clarifications.
… suggest we add an editorial comment why the term "browser-bound key" is used even though the keys are device-bound
Henna: Question: Is BBK supposed to be an optional extension, or that all SPC implementations will implement it?
smcgruer_[EST]: I would lean towards making this part of SPC.
Henna: My thinking, too.
smcgruer_[EST]: Is this a "must" as written?
slobodan: Is failure to create a BBK taken into account?
smcgruer_[EST]: I think from requirements we've heard, this is a "must"
Ian: We might need to strike a balance between "must" and "some cases where it won't happen"
Gerhard: +1 to "must" but want to be mindful of interop
Ian: I am hearing "Must" but with some variation possible depending on implementation and environment.
Henna: Reviewing the requirements more specifically....
… I have a question: how do we test for user profiles?
… what is a 'user profile' here?
slobodan: As far as Chrome is concerned, on desktop you can have separate user profiles. But on Android the passkey is available at the system level.
Henna: I'm trying to understand what behavior to expect.
… suppose I have a passkey in Chrome.
wanderview: Regarding incognito mode ... how does it interact per profile?
smcgruer_[EST]: To Ben's point, for creation we have the same behavior as passkeys. For authentication, existing BBK would be available in incognito mode.
smcgruer_[EST]: Regarding the user profile question, we can start to sort out as a WG now that we have some implementation experience.
… maybe this is an unnecessary level of requirement.
… we could say "doesn't leave the device" and then leave the rest unspecified.
Henna: How does it work in the current implementation?
… if I move to another profile, what happens when I try to get a signature?
… another use case is "if I am in incognito mode, what happens then?"
slobodan: Current behaviors on Chrome on Android:
… one profile per browser. Suppose the user is using the Chrome browser and creates a passkey; it is associated with user A (and BBK associated with it)
… if the user then goes to Chrome Beta (a different app than Chrome), we would generate a different key.
… In incognito mode will reuse a BBK from "parent" profile, but don't create any new ones in incognito mode.
smcgruer_[EST]: Android supports multiple logins....
… when you create a passkey, you choose the Android account to associate with it.
… BBKs on Chrome on Android use "Strongbox" which is "per-app" storage.
Ian: Should we remove any requirements related to accounts, or just provide hints?
smcgruer_[EST]: Let's look at the ideal world. Is the following a reasonable statement?
… a BBK would be persistent and available on the same physical device for a given passkey but would not leave the device.
… in theory, multiple browsers might have access to the key
Doug: +1
Henna: +1
Henna: Concept of user profile is complicated, especially if inconsistent across device.
Gerhard: On mobile phones, app isolation suggests that we should not blur boundaries
… I would perhaps restate the requirement that the BBK should be "within that browser instance only on that device"
… I think that aligns with paradigm about how other things work.
smcgruer_[EST]: On desktop, it's not obvious to me that we will go beyond user profile.
ACTION: Ian to work with Henna and Gerhard on update expectation about scope of BBK and "not leaving the device"
Henna: How is a BBK deleted?
… can it be deleted independent of the passkey?
Slobodan: If you delete the app, you'll still have the passkey but we delete the BBK (which is associated with the app)
… additionally there might be some amount of privacy concerns
… there are other times it might be deleted independent of the passkey
smcgruer_[EST]: We are planning to delete BBKs that are unused.
Ian: I am hearing (1) the browser will make a best effort to delete (eventually) any associated BBKs when a passkey is deleted and (2) a BBK may also be deleted in other circumstances.
Henna: Regarding device binding requirements, the one that's still pending is a signal about the nature of storage: "Each BBK should be associated with a signal indicating the nature of the device-binding process."
smcgruer_[EST]: I confirm that (intentionally) this has not yet been implemented. There are open questions about whether this is needed, and that it's hard to define software and hardware.
smcgruer_[EST]: The current implementation -- we only have hardware BBKs today (Chrome on Android). We are using Strongbox where available, and not doing BBKs where not available.
… we might change that in the future, but today's implementation looks like that.
Henna: From my perspective, that's ok. Again, we could just clarify that we do not yet solve for everything.
Henna: I think the clarification that, for browsers on devices that have a TPM, a BBK is created.
… and if there's no access to that, it's not created.
Gerhard: My preference would be for more signals but the offset is that you don't have an easy way to get validation that it's hardware bound.
… but I'd like the signal even when hardware is unavailable.
… it's still valuable regarding device takeover signal
smcgruer_[EST]: In the requirements doc we can make the diff clear.
… the spec has no signal but also does not constraint to hardware.
… the implementation constraints to hardware.
… the tactical approach might be to update the requirements doc with "current status"
(Ian: We'll add this topic to our action to look at the requirements.)
Ian: Thank you, Henna, for the review!
smcgruer_[EST]: Yes, thank you very much, Henna!
SPC icon management
smcgruer_[EST]: We'd like to implement support for icon management pretty quickly so this is available soon; see issue 197
… want to make this forward compatible
… want to scale across payment methods
… want to prevent against abuse
… we are focused here on the facilitating entity logos (e.g., network and issuer icons)
doug: If we did look at the 3DS use case, is there any issue with rendering what's provided in the 3DS support for SPC?
… in the 3DS spec we've specified the format for logos
smcgruer_[EST]: For SPC and 3DS we specify how to encode the payment instrument icon. Did we additionally specify how to encode the issuer/network logo?
Doug: yes
smcgruer_[EST]: I will have a look at the 3DS spec!
Ian: Regarding the design of this part of the API, for me the main design question is: do we expect user agents to know about payment system semantics enough to do the right thing with icons labeled "networK" or "issuer"? It seems to me preferable (and more scalable) to not expect the browser to know about payment system specifics and to empower the party calling the API to exercise some control over positioning of the icons. So do you think user agents will know about payment system specifics?
smcgruer_[EST]: Practically speaking, no.
… we should spec SPC so that it can work with the browser not knowing something, but perhaps the browser could catch up
Ian: On GitHub I had suggested minimal positioning expectations (e.g., "right/left or up/down") because that's closest to what the developer might be thinking.
smcgruer_[EST]: We could also punt this in v1.
Ian: Could we instead in the spec say that (1) the order of icons passed to the API is meaningful, but (2) we are intentionally underspecifying the exact rendering by the browser at this time. This would give developers the opportunity to change the order and see an impact, without constraining the spec for now.
<benoit> is it more of a "precedence" rather than "order"?
smcgruer_[EST]: That's what I had been planning for, so can work with that
Ian: We would just want to say that explicitly and include a Note that it's not fully specified.
smcgruer_[EST]: In my draft spec, I say that the UA can remove icons (e.g., if too many are provided), but removes from the end of the list.
smcgruer_[EST]: the other big question is what to do with aspect ratios and pixel density
Ian: I'll put this back on next week's agenda as part of hearing back from the EMVCo 3DS WG on the latest UX mockups.
Expanding output states for SPC
smcgruer_[EST]: As we have discussed previously (issue 275) we would like to provide more information to integrators about SPC failure modes so that they can decide how best to proceed. We have some proposed text for the specification to add new output states; please review pull request 292.
Rechartering update
Ian: We've announced the WG decision to request W3C Member review of our revised charter. We have received 3 of 5 horizontal reviews of the charter (all positive with no change requests) and are allowing another 10 days or so for the other two. After that we expect to start Member review in early June.
TPAC 2025
Ian: TPAC 2025 takes place 10-14 November 2025 in Kobe, Japan. As in recent years, I propose that the WPWG meet on Monday and Tuesday (10-11 November). Then there will be Breakouts on Wednesday, and I expect the Web Payment Security IG to meet on Thursday. I plan to ask for meetings on those dates.
Next call
22 May
Ian: We'll take spillover items and 3DS WG feedback