Meeting minutes
SPC matching BBKs
Stephen: We've been working on browser-bound keys in BBK. We have a prototype behind a flag. We also now have a pull request for to add BBKs to the specification.
Stephen: we think this reflects what was in the issue (271)
… one partner raised a topic -- they would like to be able to only trust a set of known BBKs
… they will get a BBK on creation, and that's the one they want to trust
… they want to avoid a double authentication problem.
… when second BBK issued, there would likely be another step-up to start to trust the second BBK.
… but then the question is: why do we need passkeys if we are just using single BBKs?
Gustavo: The reason we wanted BBK is for device binding. There's no way to know which device it is until the user starts interaction.
… I've talked to banks and I think they've said "if I can't prove to regulators that the user went through some device-binding that I trusted" it wouldn't work for them
Gustavo: Banks are using their own banking apps in many cases (rather than OTP)
… when the user does 3DS there's an out-of-band interaction; regulators trust the app approach.
Stephen: Understood. The statement here is -- for the second factor we need to have proof of possession of a *known* device (although it might not be the *current* device)
Gustavo: The BBK binding process might need to go through a banking app they trust.
Stephen: we've heard that first BBK created along with passkey creation is acceptable
… generating the second BBK (at authentication) is the challenge
stephen: You can avoid 2 authentications by having a BBK accept list...send user to fallback flow in this case but they won't be authenticated; they will be shunted back for a single step-up
… downside of this is that it makes the passkey useless
Doug: I want to point out in terms of the second authentication; not every country has SCA requirements. There's value in the BBK when it's generated on a new device.
… the trust that comes into the first BBK is variable. There are other signals that the RP might have including fingerprinting, checking SIM
… if you get a new BBK but it fits into a situation where you've seen the device, you may not need to challenge
… having a fallback ux when there is no match tests poorly
… not sure there's a need for the bbk accept list but if so, option
Ian: See also DBSC, trust signals, and other ways to get trust. In other words: perhaps it will be commonplace to find a sufficient trust signal present to then trust the newly minted BBK.
NickTR: Can you say "must use synched passkeys"?
Stephen: WebAuthn only allows hints, and platforms are generally synching
Rene: I think DBSC would not work in the case of SPC because the cookie is bound to the session of the merchant.
Rene: Extensions for either webAuthn or CTAP can be used by any authenticator
… there might be interest in an extension to hint to authenticators to not have a syncable key
… I was going to bring up RPK (relations public key)...finding a signal that would be device-binding-ish where the key is transferred through a proximity signal or it gets signed
… I have a question -- has there been input from platforms here about implementing BBK?
Ian: Beyond BBK specifically, we are still looking for more browser implementations of SPC.
Jean-Luc: There's a WebAuthn L3 flag on backup-eligibility.
… this flag could send a strong signal whether the RP wants this credential to be synched or not
Stephen: I think that's an output property; the authenticator decides the value but there's no way to request a particular value
JL: We think DBSC + CHIPS would be useful here; combining SPC with this
JL: Regarding the proposal of "BBK accept list" to avoid double authentication; that seems to be the equivalent of registering a new device.
… there's an opportunity to request BBK after step-up
Gustavo: Could a key be created after a 3DS step-up?
gustavo: What would experience look like for user when they engage again? Would they have multiple passkeys? How would they know which device is which?
Ian: Can we add key after step-up? Or describe fallback authentication as one input to SPC (a topic we've looked at in the past)? For instance, if there's no BBK on this device, a 3DS flow is triggered automatically to step-up the user, and after that flow completes, a BBK is created and returned in SPC output.
Stephen: There would likely privacy issues in a flow like that ("ah, there was no bbk in this case!")
Ian: It's not immediately obvious to me that an ACS would distinguish a 3DS flow that was initiated by the merchant pre-SPC from one initiated by the merchant within-SPC.
[We discuss in more detail the UX of double SCA situation]
Gustavo: 2 SCA is a one-time thing (cf onboarding a card in a payment app and first doing faceid then doing OTP)
Fahad: In digital credentials discussions they are looking at this topic of "inline provisioning"; there haven't been privacy issues raised.
… so you could give a provisioning URL if a key does not exist
… and the user completes authentication within that URL and then processing continues depending on the outcome of the process.
… so check out what DC folks are doing.
… second topic - if we get an SPC error (fallback UX) and we do a 3DS call, would you then need to do a second SPC call?
Stephen: It feels like if we haven't authenticated the user we can't simply give you a new BBK.
… if you want a passkey with a bbk that you trust, you need to do some sort of WebAuthn before or after you do the step-up authentication. That's the binding.
[Nick walks through his understanding of the flow]
Nick: Is the objection that there's never a second authentication, then it's broken. But if you can have a step-up once for a new device, then everything's ok.
Fahad: You're right that the concern is that on a new device, you'll see the payment sheet and the user will do biometric. Then after that because the device is new, there would be a step-up by the issuer.
Ian summarizes three things he heard about the double authentication: (1) not a problem at all (2) not likely a common problem (3) inline provisioning might be an option (cf. fallback flow in SPC)
Rene: Question is what amount of user friction is acceptable when onboarding a new device?
… do you want to require the user to log into a financial institution after an authentication failed, or do you want to do something with a synched passkey where you will end up doing the re-authentication inline which likely means less friction.
… do you need the user to onboard the device in an app or a 1p context?
… but I think there will be a second authentication regardless.
JL: My understanding is that, to know there's a bbk, we need to go through SPC.
Stephen: Correct
JL: That means in this case, I would be concerned about whether same factor type (e.g., biometric) used twice; which might not satisfy regulation
JL: What about using DC API for second factor?
Stephen: relationship with DCI needs to be worked on more; lots of unknowns
Charter
https://
[Ian reviews changes in charter]
Ian: The draft charter does not include a plan to get PR API back to Rec; that is something the chairs and group will need to discuss further..
Stephen: We are still interested in the PR API and PH specs; supportive of that work
Ian: Please give feedback on charter within 2 weeks
nicktr: Regarding PR API ... WebAuthn use L1, L2, L3 language for versioning
… should we use similar language to provide greater clarity?
NickTR: Payments industry may want revision numbers.
Stephen: -1 to versioning info
… for WebAuthn, the levels are not really observed by implementers
Rene: Levels are additive
Next meeting
<Ian> Next meeting: 24 April