Meeting minutes
SPC
Ian: Three capabilities seem clear:
* BBK feature detection
* Allow list
* UV=discouraged
Ian: These should support a variety of 1FA and 2FA use cases.
stephen_mcgruer: This would be easier to discuss if we wrote it up
presetn+ Rene_Leveille
tomasz: In SPC there's no way to set UV today...so this why we are talking about a spec change
Ian: What is the assessment of the implementation cost for these three features?
stephen_mcgruer: Feature detection is underway; should not be too costly.
… adding an allow list for BBKs and uv=discouraged does not appear to be a big amount of work, but the big question is whether uv=discouraged is supported.
… so some work will need to be done to understand the cost of getting support for uv=discouraged.
John: Windows Hello uses user verification to unlock storage, so "discouraged" not likely to work there in the short term
John: It was also previously baked into Android, but that may have changed at some point.
… for technical reasons it may not be able to unlock the private key without some sort of user verification action by the authenticator
Isaiah: I think MacOS also upgrades uv=discouraged
Tomasz: Maybe we should go back and talk about why we need this.
… one flow we have in mind is user is authenticated in one flow and then we want to use SPC after that, so we already know the user.
… where we use uv=discouraged or another mechanism is part of the discussion.
Ian: What about flow where BBK is in the allow list and the user does not want to go through passkey authentication.
… we might avoid uv=discouraged altogether
John: Is the BBK per credential?
… what does a BBK mean without the credential?
stephen_mcgruer: We heard at TPAC that people don't want to walk away from passkeys.
John: There's a different privacy question if I annotate something to a passkey that is already uniquely identifying for a person...but when I remove the person and it's just about the device....
stephen_mcgruer: We heard at TPAC strongly that the passkey does not represent a person
John: RP shouldn't be able to correlate between persona A and persona B based on a passkey.
stephen_mcgruer: If I create two passkeys for the user (for persona A and B) that's what those keys are for.
John: Let's just be clear about what passkey flow is being eliminated.
Tomasz: If user is authenticated with passkey for login, the same credential ID is provided to PSC.
Ian: If you get a new BBK, do you need to step up the user again?
Tomasz: I don't know yet.
John: It's the same device in the authenticated session, but it's still a new device.
ACTION: Ian to work with Stephen and Tomasz on write up of how features will support 1FA and 2FA use cases (feature detection, uv=discouraged, and allow list)
[Regarding roaming authenticators]
Ian: Would it meet your request to support roaming authenticators that are immediately available
Bjorn: That is a good starting point, yes.
… Yubico is interested in this and the reqs doc says that it should be supported.
… we can do a write up for how it could be supported.
John: I don't know whether "Using an immediately available authenticator" should not involve much change to the spec
https://
John: We did add the 3p flag to CTAP
… (2.3)
John: I think this is mostly an implementation question, for whoever is doing the credential provider selection.
John: On Android there is a credential provider selector that's not currently used by SPC
ACTION: Bjorn to write up the path forward for SPC to support roaming authenticators.
Bjorn: I'll work with John and Stephen.
Facilitated Payment Links
Ian: We talked about comparing different options.
Stephen: Yes, we own the next steps on that
ACTION: Stephen to work on comparison of different ways to smooth the handoff (on mobile) from web checkout to native payment app
Next meeting
29 January