Meeting minutes
Browser-based key in SPC next steps
(Slobodan Pejic walks through proposed changes to SPC for a BBK)
Slobodan: We plan to augment the payment extension in webauthn to communicate the BBK
Slobodan: Some development work is happening in Canary that has not quite landed but should be available soon in Canary (behind a flag)
Ian: Any surprises as you began to work on this?
Slobodan: Initially we thought we would have multiple signature, but will only have one
… we had thought about algorithm transitions and thought about cross-signing but that's rare.
Doug: Thanks for the update....I didn't quite understand the bullet point on registration.
Slobodan: When we generate a passkey in a 1p context, it's a different context from the assertion. The browser-bound signature should be available when the passkey is created.
… info would be in the client extension outputs
Ian: Anything changed in the Chrome built-in UX?
Slobodan: I don't have details there.
Ian: Are keys always created?
Slobodan: Yes, if payment extension is set. And may depend on availability of platform support.
Ian: Any updates on attestation?
Henna: We wanted to go back to check on threat model. The general concern is that when the device-bound key is created, is there a way for it to come directly from the platform (rather than the browser)?
Slobodan: Attestation in any case will not be part of first build
JeanLuc: How is the lifecycle of the BBK managed?
(See our requirements doc)
Slobodan: We have some options on this. E.g., we might delete and recreate a key if signing algo changes
… and treat it as a new key
Jean-Luc: If you create a new BBK for a credential, is there a way to keep a trace of the previous one for the purpose of chaining?
Rouslan: That won't work, for example, if the user has multiple devices.
… regarding user ability to delete the BBK, the user can do things like "clear browser data' and that should clear the keys
… switching profiles should also work
Ian: Slobodan, do you have any questions for the group that would be helpful for you?
Rouslan: General question is whether doing this will satisfy device binding requirements for the industry.
… we're trying to provide an approach to bind a key to at most one device.
… what in the industry would need to chance to accommodate this new key (e.g., in 3DS)
Gerhard: I think there's a mandate that something like dynamic linking must be done. If the device bound key is used to sign a payload I think the requirement will be met
Doug: From a 3DS side we'll be reviewing this and confirming this; I think it's not likely necessary since this is being done as an extension.
Doug: I assume the key is being created by the browser. Could it be created in the browser in a way that is protected from the JS layer?
Rouslan: Yes, it's protected from the JS layer.
Gerhard: Is device bound key merchant bound?
Ian: The BBK reqs doc currently says: "In private browsing mode, if a user can access passkeys when using SPC, the user agent should also return the BBK."
Slobodan: That still resonates for me.
Gerhard: +1 to being able to use in incognito mode.
Slobodan: Regarding cross-origin access, the key will be available cross-origin.
Gerhard: How complex would it be to add this concept to a payment handler, to complement other payment mechanisms.
… I'm talking with industry players who could be interested in a BBK for payment handlers themselves.
Ian: Different context than SPC, so we should separate that discussion
Jean-Luc: How would the signal about the device binding mechanism would be reflected?
Ian: Would you expect this signal about how the key was managed to be available in the first release of support?
Slobodan: That is not currently in the proposal because it may overlap with the attestation discussion.
Jean-Luc: For financial information, this information is very important.
Slobodan: I can take that as feedback. So far the initial proposal does not include that.
Henna: Regarding usefulness to industry, I think yes. If we can prove that the key is coming from a TPM and bound to a device, it should be ok.
Jean-Luc: I see synergies with DBSC. Is this key isolated from other initiatives?
IJ: From TPAC discussions I took away two aspects to that question: (1) The keys themselves should not be shared between the two APIs because there are different expectations about them in the two APIs (e.g., one says keys should be available cross-origin, the other says not to do that.). (2) The technologies should all be considered as part of building a good experience, because having multiple keys available may lead to better UX (e.g., having established a previous DBSC session on an origin might mean no step-up is required the first time the RP sees a new BBK).
Doug: When might this be available for testing?
Slobodan: I estimate "early Q1" in Canary behind a flag.
Payment request question about camera access in handler
Ian: Limitations today may mean you can't do facial recognition in a payment handler. That's the issue that was raised.
rouslan: We've not received feature requests from primary partners.
… are there partners who want to use payment handlers who want to experiment with this, please let us know.
Ian: Gerhard, is that interesting to the people you're talking to?
Gerhard: Absolutely. Selfie identification in payment handler would be an important capability.
… would it be a disqualifying thing if we can't? Probably not. But it would help.
… the reason I'm looking into payment handlers relates to FIDO adoption in the banking industry.
… so being able to use a camera for other types of authentication is important.
Next meeting
Gerhard: I will be presenting on payment fraud at the Antifraud CG on Friday at noon ET
Next WPWG call: 16 January 2025