Meeting minutes
Ideas for SPC
[Gerhard Oosthuizen presentation]
<SameerT> outcome expectations apply equally to issuer (issuer also doesnt know if the credential is present on that device/removed etc)
Gerhard: We still want the API to be useful, even if a credential is not available.
… so part of the proposal is that SPC be a confirmation, not necessarily always a challenge.
Gerhard: So there are three main proposals and some sub-proposals:
A. Always show the SPC dialog and make WebAuthn conditional
B. Provide a clear error to what happened on SPC page
C. Generate a browser possession signal
Sub proposals:
D. Require a transaction specific approval to allow signal generation
E. Don't allow JS/HTML to access/edit the signature
F. Allow a PaymentRequest caller to decide if WebAuthn is required
G. Enable users to opt out of sharing a returning browser signal
H. Allow registration to be silent
[Gerhard shows slide about how the 8 proposals address the four main obstacles he cited]
Ian: what is value of having both a browser signal and webauthn signal?
Gerhard: Device info.
Rolf: Where can privacy come from?
Gerhard: Let's dig in.
* Generated keys would be bound to a top-level/3p origin pair
* Signature requires positive user gesture
* Keypair may be cleared
Gerhard: I think there are multiple ways the browserSignature key pair could be issued:
- Dedicated registration/issuing journey.
… this could be analogous to WebAuthn, but in software or hardware (e.g., using DBSC)
- Generate a key pair managed by the browser
- Generate a key pair as part of an HTTP Response Header by the issuer
- Use the same key provisioned by DBSC
Gerhard: We could gather user consent via the SPC dialog. The text could make clear that the signal can be used to not require a step up challenge.
Gerhard: Regarding how to trust the signal:
- Trust it increasingly over time (as is done with fingerprints today)
- Hardware-bound keys with device attestation
- Only send the signature in an HTTPS header
- Issue the key as a request in an HTTPS response when the issuer has validated the device (DBSC)
- Deliver the signature via back-channel API or .wellknown flows (cf. FedCM)
Gerhard: Suggest preference attribute: required to use webAuthn / preferred / don't use
Gerhard: one idea is an "opt out" box for possible tracking. Not a big fan for this option.
Gerhard: I think that we can increase SPC adoption if there are ways to use it without WebAuthn
… flows and sequencing are same with lower development costs
Gerhard: This would allow us to move faster in a 3-D Secure context (replacing OTPs)
smcgruer_[EST]: This is great work and well-presented. I think that the two parts about providing callers with a clear response and using consistent UX we should just do.
… agree with (1) sign what you see.
… (2) Customer consent is interesting
… (3) Privacy looks interesting but we also need to discuss.
smcgruer_[EST]: I think this is all interesting and worth looking at as a group and testing in an implementation
… we should just do the change in the flow overall
Gerhard: All improvements welcome
Gerhard: It would be valuable to have a good fallback when WebAuthn not available.
SameerT: Where you say the modal should always be displayed - say more on the options
Gerhard: Multiple options, e.g., issuer could do SPC and avoid OTP
… if the merchant adopts SPC with 3DS 2.3.1, the merchant could do the UX after the ACS says "ok to do this without webauthn credentials"
… the ACS could accept the result and still decide to do some other step-up
SameerT: So in both cases you cited, the issuer was the RP.
… so the idea is that there is a user gesture
… and only if there is a strong signature then it qualifies for frictionless
Ian: Is seeing public key again and again à la WebAuthn as input to 3DS?
Ian: I see two scenarios:
a) Registration and strong confidence in key
b) No registration and gradual trust in key
Gerhard: But there's a third option where is late key pair generation (after HTTPS response), where the key pair generation is done by the issuer and sent to the browser.
Ian: What would be needed in 3DS to do a minimal version of this?
Gerhard: 3DS already has a way to handle "no credentials" and also proof.
… there's no place yet to handle 2 signatures or pref.
Sameer: Looking at the options on slide 19, I think 1, 3, and 4 could be done today
… I think delegated key pair version could be handled.
… we'd need to look at case of empty credentials and tx dialog.
… if 3DS method can do this in hidden iframe, then that's possible
Gerhard: One thought i had - what if we use a payment handler (service worker) that kicks of SPC without showing a payment page to begin with.
… so the issuer could use a payment handler without a page, just to kick of SPC
… that way the merchant would know the secure display was coming from an issuer context
rolf: What would happen if there are no credentials? I'm thinking of w3c/
… so your key-that-gains-trust over time might be do-able with WebAuthn
Gerhard: Issuer would still need to be able to manage webauthn credentials.
Ian: That's not clear to me. It's not clear you need a FIDO server to determine over time that you can trust a public key; this is not about validating an assertion.
Gerhard: Can the key pair be generated without biometric?
Rolf: You should be able to get a key with user consent. And could be generated automatically. See issue related to get/create operation. I think the predictability is valuable.
… what the issuer does with the credential is up to the user. E.g., in the future the issuer could ask the user to confirm it's really her.
Gerhard: I don't want people to treat something that is not a MFA signal that was not created as such.
Next meeting
14 March
Ian: Sorry, Stephen had some chrome info we didn't get to and we'll talk about at next meeting