Meeting minutes
SPC capabilities explainer
Secure Payment Confirmation Capabilities explained
Darwin: Explains the Secure Payment Confirmation (SPC) Capabilities API
… explains the API (and design choices)
Ian: What's the status of implementation?
Darwin: Will come out in Chrome 148 (stable release is 5 May)
BBK guarantees
John: I would like more time.
… and I will add notes to w3c/
Stephen: We've not yet made changes to the spec based on #321. The main action had to do with wording in the spec about bindings. We think it's currently implicit, but we can make explicit.
Various SPC topics
Ian: Any updates on conversations with the Google password manager team on how we might address double step-up use cases?
John: uv=discouraged is supported in some places (webauthn, roaming authenticators)
… some passkey providers ignore it even though the capability is enabled for other situations (e.g., laptop lid case)
stephen_mcgruer: Ian's question is about specific authenticators in the SPC context
John: "Of the authenticators that SPC supports" makes sense.
stephen_mcgruer: We had conversations with google password manager folks. Generally on android you need a biometric to get to hardware where keys are stored.
<renebl> I thought on windows Hello always did UV regardless of the flag as well. Though I should go verify it as well
stephen_mcgruer: on desktop uv=discouraged could work with google password manager
stephen_mcgruer: I can see a path for making this happen on desktop platforms for *certain* authenticators. It's likely not ever going to be supported on Android.
… because of the fundamental requirement for biometric to get to key storage
Ian: Any other ideas circulating?
John: Only option would be to not use the platform authenticator (on Android)
Stephen: We haven't thought much more about this. In terms of uv=discouraged, that's the end of the story re: password manager on Android.
… we've not yet spent time on the double step-up story through other means
Ian: The other option suggested was to move SPC architecture into WebAuthn
John: If we wanted to do the mental exercise of making this work with hybrid (e.g., credit cards as FIDO authenticators use case),
… all the client data is collected in the initial browser and cached there. Which means that the authenticator has no place to put payment transaction information.
… we've heard some pushback from banks about possibility of a MITM attack in hybrid case, where you can't trust a hijacked browser.
… so there's a desire in WebAuthn from some folks to have a signal from the remote authenticator that the authentication happened over hybrid.
… if we did something like that, we could generalize to include SPC type functionality.
… you can imagine a different type of flow where the user says "I want to use my phone to do SPC" and the payment info would be presented on the phone rather than the desktop.
… that would be a different model where the authenticator or the credential provider was doing the SPC presentation
… you'd still have a BBK associated with the desktop
Ian: I recall discussing this model (more abstract) years ago.
John: Because data for clientData comes from browser, it makes doing hybrid in a trustable way very difficult
Ian: Does this relate to the "Instagram" topic (apps that are not browsers but how they get webauthn capabilities for hosted content)
John: Today you can't do WebAuthn in a web view for security reasons. But we received a request for other apps to have webauthn capabilities.
John: If people can't use webauthn and a web view and making people fall back to username/password, are we shooting ourselves in the foot?
John: SO, an approach would be to have the authenticator or credential provider be the one that presents the transaction dialog and creates the object.
Next Meeting
9 April