17:02:31 RRSAgent has joined #wpwg-spc 17:02:31 logging to https://www.w3.org/2022/01/10-wpwg-spc-irc 17:02:43 Meeting: SPC Task Force 17:02:58 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2022Jan/0001.html 17:03:01 Chair: Ian 17:03:03 Scribe: Ian 17:03:05 present+ 17:03:07 present+ Rolf 17:03:09 present+ Doug 17:03:15 present+ Stephen 17:03:18 present+ Laura 17:03:42 present+ Tim_Casppalli 17:03:44 present+ Praveena 17:04:19 https://lists.w3.org/Archives/Public/public-payments-wg/2022Jan/0001.html 17:04:52 Topic: Checking in on WebAuthn discussions 17:05:14 agenda+ RPID proposal and WPSIG discussion 17:05:40 Tim: There was some discussion that happened today re: header 17:05:58 ...a concern is a malicious site prompting for payment. 17:06:12 ...would a CORS-like header help? 17:06:53 present+ Werner_Bruinings 17:06:57 present+ Sameer_Tare 17:07:11 werner has joined #wpwg-spc 17:07:27 Tim: I do kind of agree with Yubico's view: 17:07:49 https://github.com/w3c/webauthn/issues/1667#issuecomment-1008886214 17:08:25 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 17:08:42 Tim: There's a parallel to cookie prompts. That's a known user behavior. 17:08:58 Stephen: In the SPC case, you need to identify the credentials for the user you want. That's possible (but requires some effort). 17:09:18 ...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. 17:09:24 ...you have to solve those problems first. 17:09:32 ...then you have to have a user activation. 17:09:42 ..then the user has to go through a payment prompt. 17:09:46 ...they have to say no or yes. 17:10:03 ...if they say yes, then they need to complete a web authentication. 17:10:19 ...and the attack only works if that's actually the person you were trying to attack 17:12:13 Ian: How can we advance discussion on this in CTAP WG and in platform authenticators? 17:12:22 Tim: JohnB would have to make the case in the CTAP WG 17:12:31 q+ to comment vaguely on Android 17:13:13 https://github.com/w3c/secure-payment-confirmation/issues/157#issuecomment-993877775 17:14:32 SameerT has joined #wpwg-spc 17:14:41 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. 17:15:08 qq+ to comment on downsides 17:15:17 ...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. 17:15:43 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. 17:15:59 ...e.g., on Windows, the WebAuthn disambiguation page mentions the RP 17:16:15 ...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. 17:16:54 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) 17:16:55 q? 17:16:56 q- 17:17:00 ack 17:17:29 Rolf: So there was a proposal to add a bit. 17:18:10 ...you would need to create an extension. 17:18:16 ...you would need OSes to pass through 17:18:20 ..and authenticators to implement it 17:18:27 ack Sm 17:18:27 smcgruer_[EST], you wanted to comment vaguely on Android 17:18:30 ack me 17:19:08 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) 17:19:20 rolf: You could consolidate with the protected confirmation dialog as well 17:19:47 ...protected confirmation is a native api that can be used to present a dialog that cannot be spoofed by anyone. 17:20:06 ...the signature provides non-repudiation (like SPC does for payments) 17:20:24 ...protected confirmation was implemented in a non-FIDO way. 17:21:07 ...so you may end up with 3 techs in Android: Protected Confirmation, FIDO, SPC 17:21:21 ..it would be great to build it all on FIDO 17:22:18 for Android Protected Confirmation, see https://source.android.com/security/protected-confirmation 17:22:46 Ian: Could experimentation happen in platform authenticators? 17:22:59 Stephen: In theory. 17:23:05 q+ 17:23:08 Rolf: Security keys could as well. 17:23:24 ...but platform authenticators don't benefit from CTAP 17:23:34 ...whereas security goals have a goal of inter 17:23:41 s/inter/interop 17:23:58 ...from a functionality perspective, the platform authenticators still need to so the same thing. 17:24:36 ack Sameer 17:24:50 SameerT: If we go down path of additional bit, I have some questions. 17:25:02 ..first, I assume this would happen at credential creation time. 17:25:25 ...first, I assume that there would be re-enrollment needed 17:25:26 [yes] 17:25:41 SameerT: I think user education will be important. 17:25:53 ...if 3p bit is not set, where does validation happen? 17:26:36 Rolf: Technically, the browser needs to understand whether to trigger the API in a 3p context. 17:26:47 ...so ideally the browser asks the authenticator and gets some information back. 17:27:11 ...suppose I'm a browser and someone inserts a security key. 17:27:23 ...I need to wait for the key to be plugged in before telling the user "you can't use this" 17:27:47 ...it might be different for platform authenticators; the browser can ask the platform authenticator "does this credential work for you"? 17:28:02 ...so the authenticator doesn't enforce anything; they don't know it's a 3p context. 17:28:35 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. 17:28:59 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. 17:29:34 ...in the end it might be cleaner to say "which dialog is presented is not in control of the authenticator" 17:30:11 ...remember that the 3p context usage is visible in the assertion and the RP can reject it if they want. 17:30:26 SameerT: In 3DS use case there needs to be a fallback scenario. 17:30:34 qJ? 17:30:55 smcgruer_[EST]: You have to trust the browser (whether WebAuthn, SPC, or anything else) 17:31:37 ...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. 17:31:49 ...e.g., type of credential, amount, etc. 17:32:07 ...Rolf is also correct that the browser should also be able to prevent some things that should not happen from happening 17:32:26 ...also agree the authenticator can't know it's in a 3p context. 17:33:53 Topic: 17 January meeting 17:34:01 (Next meeting) 17:34:06 RRSAGENT, make minutes 17:34:06 I have made the request to generate https://www.w3.org/2022/01/10-wpwg-spc-minutes.html Ian 17:34:09 RRSAGENT, set logs public