Meeting minutes
Introductions
[Zane Durkin]
Browser-based key in SPC next steps
Pull request for security requirements
ian: Let's walk through the pull request. In the section on "device binding" some of the text was inspired by an EBA supplemental note with the goal of helping to ensure it is appropriate for regulatory compliance
… and noting that "no device binding" may still be a helpful signal
… the private browsing mode is aligned to the webauthn behaviour
… and also noting explicit reliance on the underlying FIDO security assumptions
<Ian> ------
<Ian> Parties that call SPC directly need to trust the user environment to a certain degree, consistent with the FIDO threat model.
<Ian> However, in a delegated authentication scenario (e.g., when the merchant or their payment service provider conducts the SPC
<Ian> registration), additional security measures are necessary so that other parties (e.g., the bank or network) can trust that the
<Ian> authentication took place on a user device and was not spoofed (e.g., through a cloud service). An attestation from
<Ian> secure hardware can provide additional confidence about the context of the user’s authentication.
<Ian> smcgruer_[EST]: My belief was that the fact that we are relying on web authn defeats that particular concern. Even in the delegated model, the RP created the passkey in the first place.
Ian: In my scenario, the passkey is owned by the merchant.
smcgruer_[EST]: Ah ok, if you don't trust your merchant than something might need to be done.
… but couldn't the merchant just proxy this to a device like a particular device?
… let's say a malicious merchant decides to "register a passkey" for Stephen, but I just use a fleet of real devices.
… I register a passkey for "Stephen" on device 700
… here's a real attestation for device 700
Fahad: That might be possible.
Gerhard: Some ID&V would happen before this.
… fundamentally, because no platforms do attestation, why would you need a bank of phones? If the binding is malicious there's know way to know it was FIDO in the first place.
… if it's broken at the start, it's broken forever.
smcgruer_[EST]: Agree that if there's no attestation for the passkey side, then they could just as easily do it in web crypto
smcgruer_[EST]: To defeat a substitution attack, you would need a strong identifier as the RP.
nicktr: Attestation would only give device class, not individual device.
Gerhard: I am intrigued the the FedCM model where two parties are in place (web site, identity provider). Could we do something similar with SPC? Suppose the browser could talk with the bank directly (assuming they are the RP) and communicate information about the user device.
smcgruer_[EST]: As long as the issuer were involved in a 1p moment with the customer on this device (e.g., the issuer drops a cookie) and later the browser talks to the issuer, the issuer could check whether there's a cookie...you might be able to provide enough assurances.
… but is this in our threat model.
Nick: I had always anticipated that there would always be an interaction between user and issuer at time of credential creation
Ian: SPC does not require a first party interaction (in delegation scenario)
Nick: Credential is created on a challenge screen; that's when initial registration of authentication credential takes place.
Ian: Can we move forward with the "other pieces" of this pull request or do we need to wait for attestation requirements?
Gerhard: Maybe we could put something out first to get learnings and add other bits based on fraud we detect.
NickTR: I think we need to hear from the schemes and issuers about whether this would work for them or not
smcgruer_[EST]: We have someone who has started work on this.
fahad: Can we discuss details about how this would work?
… for example, would the BBK be created at WebAuthn registration time?
… from our perspective we would strongly prefer BBK creation at WebAuthn registration time after an ID&V.
… for us to trust seeing a new BBK at authentication time, we'd need to do another ID&V
smcgruer_[EST]: The WebAuthn folks do not like the idea of one-passkey-per-instrument; just note that...they think of passkeys as per-account.
… we are amenable to creating the BBK at WebAuthn creation time.
… however, for synched passkey you will still want a BBK on the new device.
Ian: Even if in the login use case additional step-up on synched devices may not be required or expected, my understanding for payments use cases is that it would be an acceptable (and even expected) user experience for the user to be stepped up on each new device.
<Gregoire> agreed with Ian
Gustavo: We have heard from banks that step up on new device is ok UX.
… also, if you get a new device, cards can be ported to the new device, but you still need to do ID&V to the bank before you can start using the card.
… new token generation
Fahad: Yes, we expect that for a new device, step up is ok
<SameerT> RPs can consider a registration and re-auth (without existing BBK) to be the same event. The BBK framework could do the same
ACTION: Ian to add a UX expectation that an ID&V at time of creation of BBK on a new device is ok UX
smcgruer_[EST]: We will see whether "on registration" generation of BBK is in the plan
smcgruer_[EST]: I have a more fundamental question -- should we not be doing synched passkeys at all because they are not compatible with payments expectations?
NickTR: FIDO allows for both types.
smcgruer_[EST]: FIDO says that, but some platform authenticators always sync.
Gerhard: I think we can help by creating low-friction experience sooner.
<Sue> Stephen - correct....BE= Back up Eligible, BS= back up supported.
Ian: Would it be useful if BBK only used when passkey is synched?
smcgruer_[EST]: probably not
next meeting
5 December
Ian: At that meeting I expect we will return to the BBK topic to look at any progress from the Chrome side, and any new input related to attestation or other requirements. We'll also put Payment Request issue 1039back on the agenda.