Meeting minutes
Checking in on WebAuthn discussions
Tim: There was some discussion that happened today re: header
… a concern is a malicious site prompting for payment.
… would a CORS-like header help?
Tim: I do kind of agree with Yubico's view:
https://
Stephen: I think that opt-in provides sufficient protection. I think the chance of a user being attacked by this method is so very low, this would be IMO a non-issue
Tim: There's a parallel to cookie prompts. That's a known user behavior.
Stephen: In the SPC case, you need to identify the credentials for the user you want. That's possible (but requires some effort).
… then you need to find the user you want to attack. You need already have a good idea that this particular user is the user you want to attack.
… you have to solve those problems first.
… then you have to have a user activation.
… then the user has to go through a payment prompt.
… they have to say no or yes.
… if they say yes, then they need to complete a web authentication.
… and the attack only works if that's actually the person you were trying to attack
Ian: How can we advance discussion on this in CTAP WG and in platform authenticators?
Tim: JohnB would have to make the case in the CTAP WG
https://
Rolf: If I am owner of a credential, I don't see any need to distinguish SPC from login uses. Any credential should be usable for both; I am the credential owner and can distinguish the use cases and reject where I don't want it to be used.
… even in the 3p use cases, I have some challenges seeing the downside of 3p use of SPC credentials since the RP can see whether the data is SPC or non-SPC.
smcgruer_[EST]: I understand that most of the downsides are about user experience. SPC allows an RP to show up in an experience not controlled by the RP.
… e.g., on Windows, the WebAuthn disambiguation page mentions the RP
… so you might see "Plug in a security for foo.com" and Foo might not wish for that to show up if it's not in their control.
Rolf: Foo would be able to see whether the assertion was triggered one way or the other, so there's no point anyone doing this in the first place (since the RP can reject the assertion)
ack
Rolf: So there was a proposal to add a bit.
… you would need to create an extension.
… you would need OSes to pass through
… and authenticators to implement it
<Zakim> smcgruer_[EST], you wanted to comment vaguely on Android
smcgruer_[EST]: We've been looking at SPC on Android again. I would make the vague statement that we are likely to experiment with the API that SPC needs (prior to full adoption of discoverable credentials)
rolf: You could consolidate with the protected confirmation dialog as well
… protected confirmation is a native api that can be used to present a dialog that cannot be spoofed by anyone.
… the signature provides non-repudiation (like SPC does for payments)
… protected confirmation was implemented in a non-FIDO way.
… so you may end up with 3 techs in Android: Protected Confirmation, FIDO, SPC
… it would be great to build it all on FIDO
<Rolf> for Android Protected Confirmation, see https://
Ian: Could experimentation happen in platform authenticators?
Stephen: In theory.
Rolf: Security keys could as well.
… but platform authenticators don't benefit from CTAP
… whereas security goals have a goal of interop
… from a functionality perspective, the platform authenticators still need to so the same thing.
SameerT: If we go down path of additional bit, I have some questions.
… first, I assume this would happen at credential creation time.
… I also assume that there would be re-enrollment needed
[yes]
SameerT: I think user education will be important.
… if 3p bit is not set, where does validation happen?
Rolf: Technically, the browser needs to understand whether to trigger the API in a 3p context.
… so ideally the browser asks the authenticator and gets some information back.
… suppose I'm a browser and someone inserts a security key.
… I need to wait for the key to be plugged in before telling the user "you can't use this"
… it might be different for platform authenticators; the browser can ask the platform authenticator "does this credential work for you"?
… so the authenticator doesn't enforce anything; they don't know it's a 3p context.
SameerT: If an issuer sends back a list of credential IDs in a 3DS context....the browser would not know that the bit is set.
Rolf: The Browser would provide the list of IDs to the authenticators and get back information on which ones can be used in a 3p context.
… in the end it might be cleaner to say "which dialog is presented is not in control of the authenticator"
… remember that the 3p context usage is visible in the assertion and the RP can reject it if they want.
SameerT: In 3DS use case there needs to be a fallback scenario.
smcgruer_[EST]: You have to trust the browser (whether WebAuthn, SPC, or anything else)
… if we assume a trusted browser, the RP should ALWAYS verify that the credential that it receives is one it expects to receive in a given context.
… e.g., type of credential, amount, etc.
… Rolf is also correct that the browser should also be able to prevent some things that should not happen from happening
… also agree the authenticator can't know it's in a 3p context.
17 January meeting
(Next meeting)