Meeting minutes
SPC and device binding
Proposal: WebAuthn-agnostic device binding for Secure Payment Confirmation
Stephen: I plan to walk through what I posted shortly before this meeting. This is a high-level proposal for adding device-binding to SPC without relying on WebAuthn SPK/DPK
… we have heard many requests for device binding from the payments industry to meet regulatory requirements.
… passkey synching does not on its own appear to satisfy requirements. There is a DPK/SPK extension but we don't have a sense of a timeline for support in platform authenticators.
stephen: so the proposal here is to do the device binding directly in SPC.
stephen: The generated SPC key would be signed by the WebAuthn key to avoid a Man-in-the-middle (MITM) attack.
… expectation is that first time this device key appears, it would not be trusted. So there might be a step-up when it is first seen.
… however, on the same device for future authentications you would get back the same key.
… an alternative would be to register something at webAuthn registration time (using payment extension) but it would not work for extant credentials or when a 1p uses a vanilla webauthn credential.
… note that the key would be (1) browser specific on a given device, (2) available cross-origin
stephen: We think per-browser is a feature rather than a limitation.
stephen: Where would keys be stored? There are software and hardware options; I think hardware is the right move here (to reduce risk of key exfiltration).
… but there may not be a TPM available on all platforms. We would have to think about a other situations like roaming authenticators or hybrid.
stephen: Regarding privacy sharing key cross-origin, there are two consent dialogs.
… we will do a privacy review but the sense is that this is not adding issues beyond what has already been considered.
stephen: Some other topics are discussed in the FAQ (e.g., whether to offer a single-factor version of SPC where there is no biometric authentication and only the SPC key is used).
… that's an interesting situation but I'm not proposing it here; one reason has to do with the use of the WebAuthn key to avoid MITM attack.
… secondly and possibly more importantly, it simplifies the privacy store a lot if we keep close to WebAuthn's privacy bar.
… there's another topic: what if SPK/DPK does get wide interoperable adoption? If so, we have a few options including deprecation of the SPC feature.
… Ian also had an idea for defining the SPC key in such a way that it could be implemented in different ways (e.g., by browser or WebAuthn SPK).
… With respect to Device Bound Session Credentials, there are enough differences between the APIs that they are not really competing; and also their launch timeline would be much later.
Stephen: Are we reinventing the wheel with this proposal? Yes, to a certain extent. WebAuthn already addresses a bunch of topics. Our approach here should be to stick close to WebAuthn's experience. We should use the same primitives that they do (e.g,. their signing algorithms and crypto)
Stephen: Regarding device attestation, we've heard requests from the industry (in WebAuthn space) for this. On the Web there are privacy implications revealing device information, and ecosystem issues (barriers to entry for new players due to whitelisting).
… so at this time I am not proposing doing attestation with this proposal and hope that device binding alone will suffice.
… please note that at time of writing, there are only two implementations, so attestation is of limited value at this point.
Fahad: When would key be created? And who is the relying party?
stephen: It's created at authentication time using SPC payment method. It's bound to the actual party of the WebAuthn credential.
… this means that it can be created by a party other than the RP, but only when the RP has said it's ok for 3p to use their credentials.
… also, this key should not be used on its own, but only (in this proposal) in conjunction with the WebAuthn key.
… the trust in the user is from the WebAuthn credential.
… the trust in the device is from this newly minted identifier.
Fahad: In the 3DS context, the issuer would have to register the key the first time they see it.
Stephen: Yes.
<Zakim> nicktr, you wanted to ask about browser profiles
nicktr: My question is specific to Chrome. You can have multiple profiles in a Chrome instance. Are these identifiers bound to the profile?
Stephen: I suspect the answer would be one key per profile.
… Rick points out that these would be clearable keys as well
… site storage is tied to profile
… not sure yet where we will handle private browsing mode, but might issue a dummy key
Gerhard: I like the proposal.
… I was in a call last week with a financial institution and they were worried about the attestation.
… just to say that that may still be an issue.
… what domain would the key be bound to?
Stephen: The identifier would be tied to tuple of the relying party and (possibly) the credential id
Gerhard: So if I have two FIDO keys for an origin, I would get two device keys?
Stephen: Yes, at least to start.
Gerhard: That seems fine as a starting point.
Gerhard: Second topic (Gerhard shows a diagram) could we do the same device attestation and send it directly to the issuer?
… that would take away a lot of the issue related to merchant MITM attack
Stephen: Yes, that is what FedCM is doing. Usually handled via a .well_known URL. But SPC doesn't do that because the initial proposal involved explicitly the RP not being actively involved in the flow.
… if the ecosystem has changed, that may open new options.
Nakjo: I like the proposal. I'd also like to get a device key at the time of registration.
… the issuer, while creating the passkey, could use the key and remember it for this device.
… that would reduce step-ups not he same device
… I like this proposal as, in some sense, a special cookie that can be exchanged via the merchant without having a direct issuer connection at authentication time.
<Zakim> Ian, you wanted to ask about relationship to cookies (3p access, persistence) and to ask whether 3DS would need to be modified for this and to suggest device key creation at creation time as well to identify current device and to ask about regulatory satisfaction
ian: this would be available in a third party context so better than cookies
… it would be good to be relatively long-lived (but still clearable)
… if there is another key, do we have to modify 3DS?
… I was also going to suggest device key creation at key creation time
… do we have a sense of whether this would meet regulatory requirements?
JeanLuc: Thank you for this proposal. It's close to DBSC. Can we trigger the same key outside of SPC authentication?
… there's a step where the issuer would like to identify the device (as is done with DBSC)
stephen: In the initial proposal, there would not be a way. But we could look at whether the key might be available via DBSC.
JeanLuc: DBSC+CHIPS in an iframe could work. If issuer could use the same SPC key to recognize the device and not trigger step-up that would be nice.
… note that DBSC also involves a direct connection to a RP; we could imagine the issuer as an endpoint and the issuer could do device recognition.
Stephen: Both Ian and Rick thought DBSC should be characterized as distinct from this SPC proposal; not sure myself.
JeanLuc: One question is how to do key renewal
JeanLuc: The issuer might record a chain of device keys over time. Will the issuer have information about key renewal?
Stephen: I have not contemplated that. We get into concerns, however, about reinventing the wheel.
… each API has its own way of doing key management.
JeanLuc: Would this work in a custom tab?
Stephen: yes
Web Monetization topic
AdrianHB_: This relates to Web Monetization, being incubated in a CG.
… it's a declarative API for receiving payments at a Web site
… an important use cases is very low value payments without user interactions
[Slide shows payment flow]
AdrianHB_: The browser authenticates with signed http requests.
[Current provisioning and transaction flow slide]
AdrianHB_: Key is more of a session key than an authentication key.
[We review different proposals for key management]
[Ian thinks AHB should check out https://
<Fahad> Looks like a good use-case fit for DBSC, no?
AdrianHB_: DBSC only gets us half way. We want the request signed; not just the challenge.
<Zakim> Gerhard, you wanted to ask about https://
AdrianHB_: We're proposing that, for Web Monetization, the browsers would use that to make calls to the wallet as a way for the browser to identify itself
… GNAP has a bunch of ways for clients to authenticate themselves; this ties in nicely to the browser-as-client with keys
Gerhard: FedCM does some of this
Next meeting
6 June. We will return to the topic of recent news regarding payments and passkeys.