13:56:37 RRSAgent has joined #wpwg 13:56:37 logging to https://www.w3.org/2022/04/14-wpwg-irc 13:56:42 Meeting: Web Payments WG 13:56:49 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20220414 13:56:50 Chair: Ian 13:56:52 Scribe: Ian 13:57:00 Regrets+ Praveena 13:57:06 Regrets+ Nick_Telford-Reed 13:57:12 Regrets+ David_Benoit 13:57:33 agenda+ Updated on issue 172: Opt-out 13:57:47 agenda+ Update on issue 157: Cross-origin use of credentials 13:58:02 agenda+ Any feedback on UA string reduction from payments community? 13:58:06 agenda+ SPC demos 13:58:12 agenda+ Next meeting - remote 3-5 May 14:00:13 present+ Ian_Jacobs 14:00:19 present+ Anne_Pouillard 14:00:41 present+ Rolf_Lindemann 14:01:10 agenda+ TPAC 2022 14:01:23 present+ Ryan_Watkins 14:01:34 present+ Suzie_Annezo-Sebire 14:01:39 present+ Jean_Emer 14:01:42 present+ Christian_Aabye 14:02:01 present+ Stephen_McGruer 14:02:02 Rolf has joined #wpwg 14:02:45 present+ Steve_Cole 14:02:48 present+ Doug_Fisher 14:02:54 present+ Tomoya_Horiguchi 14:03:01 present+ Chris_Wood 14:03:13 ChristianA has joined #wpwg 14:03:52 zakim, take up item 1 14:03:52 agendum 1 -- Updated on issue 172: Opt-out -- taken up [from Ian] 14:03:59 present+ Jean-Michel_Girard 14:04:17 https://github.com/w3c/secure-payment-confirmation/issues/172 14:04:29 present+ Gerhard_Oosthuizen 14:04:34 present+ Michael_Horne 14:04:38 present+ John_Fontana 14:04:56 Gerhard has joined #wpwg 14:05:03 Stephen: Regarding 172, Stripe suggested that there be an ability for the user to let the RP know to remove stored data (for GDPR) 14:05:13 ...Proposal1: Stripe suggested a link to the RP domain 14:05:36 JMGirard has joined #wpwg 14:05:44 ...Chrome Team is concerned about that approach, concern that secure UX could be seen as "endorsing" link to (potentially malicious) RP site 14:05:51 present+ Chris_Dee 14:06:11 Stephen: We don't want a situation where, e.g., RP phishes (e.g., for card numbers) 14:06:12 jcemer has joined #wpwg 14:06:28 Stephen: Proposal 2 is for user to stay in the browser experience, but browser sends a signal to the RP (e.g., an assertion) 14:06:37 ...the RP does not get card information; only gets an assertion 14:06:51 present+ 14:07:02 Stephen: Both proposals involve complex UX; we are looking for input from people on whether these work, and whether opt-out required at all 14:07:26 q? 14:07:40 q+ 14:07:41 Rolf: You need a way to delete an account. Not sure the link needs to be in the SPC dialog 14:08:08 Anne has joined #wpwg 14:09:05 IJ: I think problem in delegated flow is that the user does not know the RP. 14:09:13 ...user doesn't know Stripe. User knows merchant or bank. 14:09:18 q? 14:09:19 dfisher has joined #wpwg 14:09:52 q+ to comment on per-merchant as well 14:10:06 Rolf: To whom is the user authenticating? 14:10:19 Stephen: It is Stripe (in this delegated flow) 14:10:22 present+ John_Bradley 14:10:44 Stephen: Merchant A hands authentication to Stripe who is the RP 14:11:02 ...so Stripe stores data. But the function of Stripe here is often invisible to users. 14:11:35 Rolf: Payment processors exist today. Users can tell payment processors "forget my data"; why isn't current deployment inadequate to the task? 14:11:52 ...it may be the merchant's responsibility to give link 14:12:17 jeanluc has joined #wpwg 14:12:21 Stephen: So a third alternative is that this opt-out should happen outside SPC (with a link to the RP) 14:12:35 ..I've heard an argument against that ... merchants don't want those links. 14:13:05 Jean: What happened is this - where are using our 3DS authentication to enroll credentials. At this point we need to indicate that Stripe will store information (opt-in). 14:13:18 ...since we are allowing opt-in, we need to display (at some point) an easy way to opt-out. 14:13:21 q? 14:13:23 q+ 14:13:32 present+ Nick_Burris 14:13:42 present+ Jean-Luc_di_Manno 14:13:46 ack Gerhard 14:13:56 q? 14:14:05 q- 14:14:39 Gerhard: Suppose I am shopping and I say "remember my card for future shopping" and the card is remembered by Stripe. There is a place to go to see your cards (on the merchant site) 14:15:58 ...I think it will be tricky to do this opt-out during shopping 14:16:11 ...suggest merchant gives access to partner where user can manage stored data 14:16:19 q? 14:16:43 Gerhard: This should not be in SPC dialog; rather offered by service provider 14:16:45 ack dfisher 14:17:02 dfisher: +1 to Gerhard's view 14:17:17 ...at the most recent WPSIG call EMVCo provided feedback on the opt-out issue 14:17:28 ...we don't support incorporation of the opt-out link into the SPC UI 14:18:29 q? 14:18:32 Rolf: +1 14:19:28 Ian: What are limitations of approach where SPC sends assertion to the RP? 14:19:41 Stephen: I'm hearing the critique of proposal 1 is also a critique of proposal 2. 14:19:58 ...meanwhile, the downside of proposal 2 is user understanding. 14:20:08 ...does user understand what user is opting out of? And to whom? 14:20:15 SteveC_ has joined #wpwg 14:20:29 ...the browser signal is also a bit more complex to implement (e.g., RP has a well-known domain, or server is down, etc.) 14:21:13 q+ 14:21:47 ack Ger 14:22:11 q? 14:22:18 Gerhard: The term "delegated authentication" as used here typically refers to the account provider (e.g., the bank) delegating authentication to the merchant / PSP 14:24:18 Gerhard: Store A and Store B should indicate that they are using a shared resource (e.g., Stripe) to make payments easier. 14:25:06 q+ 14:26:39 q+ 14:26:45 Chris_D has joined #wpwg 14:26:48 q? 14:27:13 Gerhard: I think there are 3 permutations: 14:27:23 1) ACS can approve context in ACS context 14:27:47 2a) Delegated auth: Merchant A shopping and Merchant A credential. Over time Merchant A credential may be more trusted over time 14:28:13 2b) SPC: PSP credentials are used within Merchant B context. 14:28:41 Gerhard: In all cases, it's important to indicate who the RP is. 14:28:44 ack jean- 14:28:46 ack jean 14:29:04 jeanluc: Key point re: delegation is who has liability. 14:29:17 q+ EMVCo delegated authentication actually delegates authentication from issuer to merchant or another party; SPC is different - the issuer still authenticating the user but via a process which involves the merchant/PSP to respond to a FIDO challenge - this does impact liability shift as Jeanluc is saying 14:30:09 jeanluc: There is both "capture" and "validation"; validation here is ultimately done by the ACS. 14:30:20 q? 14:30:26 q+ to comment that EMVCo delegated authentication actually delegates authentication from issuer to merchant or another party; SPC is different - the issuer still authenticating the user but via a process which involves the merchant/PSP to respond to a FIDO challenge - this does impact liability shift as Jeanluc is saying 14:30:27 ack df 14:31:04 dfisher: I did want to refer to one of Ian's comment about merchant-initiated and issuer-supported use cases. I want to distinguish "merchant-initiated" from what Stripe is doing. 14:31:19 ...in merchant-initiated (per 3DS) the merchant is always the RP 14:31:26 ...that distinction is important in terms of opt-out 14:31:49 ack Chris 14:31:49 Chris_D, you wanted to comment that EMVCo delegated authentication actually delegates authentication from issuer to merchant or another party; SPC is different - the issuer still 14:31:52 ... authenticating the user but via a process which involves the merchant/PSP to respond to a FIDO challenge - this does impact liability shift as Jeanluc is saying 14:32:22 q+ 14:32:38 ChrisD: I want to reinforce Jean-Luc's point. My understanding of delegated authentication is that it's where the issuer delegates authentication to a 3rd party who says that they've authenticated the shopper and the issuer "allows it to happen" 14:33:22 ...and there's a liability shift to the merchant. My understanding of SPC is that it's still the issuer who indicates whether they are happy with the response to the challenge. So it's not really delegated. 14:33:28 q+ 14:33:30 ack smcgruer_[EST] 14:34:17 smcgruer_[EST]: First, SPC is an authentication technology that can be used by lots of RPs. It can be used in any of the above scenarios. 14:34:29 ...so we should be clearer about saying "This is the integration of SPC into 3DS." 14:34:35 ..but that is NOT relevant to what Stripe is doing 14:34:49 ...Stripe is using 3DS delegation authentication ... liability being shifted from ACS to Stripe 14:35:01 Q+ 14:35:03 ....and at that point the merchant can do whatever they want in terms of authentication 14:35:12 ...and in Stripe's case, they want to use SPC 14:35:44 ...so I think this scenario is still delegated authentication. 14:36:53 Ian: So three scenarios: 14:37:01 1) ACS does ceremony + validation 14:37:09 2) Merchant does ceremony + ACS does validation 14:37:19 3) Merchant does ceremony + validation ("delegated authentication") 14:37:22 ack dfisher 14:37:26 ack Ian 14:37:39 dfisher: Logo presentation to show who is the RP is important to user understanding. 14:38:08 ...SPC is not dictating who is the RP, but if we can't address UX complexity in these different use cases, may not be usable 14:38:30 q? 14:39:33 Ian: Are we hearing Proposal 3 should get more attention? (RP works in merchant domain to show user options for managing credentials)? 14:39:58 zakim, close item 1 14:39:58 agendum 1, Updated on issue 172: Opt-out, closed 14:39:59 I see 5 items remaining on the agenda; the next one is 14:39:59 2. Update on issue 157: Cross-origin use of credentials [from Ian] 14:39:59 So are you saying 'this is not an SPC problem to solve'? If so then +1 14:40:04 zakim, take up item 2 14:40:04 agendum 2 -- Update on issue 157: Cross-origin use of credentials -- taken up [from Ian] 14:40:41 Stephen: As a reminder, this is our issue about how to integrate SPC into WebAuthn/FIDO so we can do special powers without browser cached information. 14:40:52 ...there is a proposal on the table that involves reaching out to the FIDO Technical Working Group 14:41:08 ...my expectation is that I will send a pull request in the FIDO GitHub repo (which is private) 14:41:19 -> https://github.com/w3c/secure-payment-confirmation/issues/157#issuecomment-1057208347 here's the proposal 14:41:33 Stephen: The API access that we want is well-served by the Conditional UI proposal 14:41:59 ...and so my colleagues have suggested that where we should focus is on the "bit" stored in the authenticator allowing cross-origin usage 14:42:35 ...in terms of Conditional UI I expect in the short term to focus on platform authenticators to get experience then move into FIDO for remote authenticators too 14:42:57 JohnBradley: Conditional UI is supposed to work also with remote authenticators. 14:43:05 ...only works with discoverable credentials (which SPC is using) 14:43:14 ...there's a "user external authenticator" button 14:43:30 Stephen: I think we can do something similar with SPC. We would have a "use external authenticator" button 14:43:57 q+ 14:44:28 JohnBradley: Conditional UI itself may not expose whether something is a cross-origin credential. 14:44:45 ...that's potentially a separate issue. 14:45:20 ...as an example, a Windows platform authenticator may not expose that information. If Android does it would be proprietary for the moment. 14:45:34 Stephen: Is there a standard API for "fetch the credential" under Conditional UI hood? 14:45:44 John_Bradley: There is not and may never be. 14:46:27 s/fetch the credential/fetch all credentials for a given RP 14:48:01 ack Ger 14:48:34 Gerhard: Regarding the "bit". We had said 2 potential bits: (1) Enable payment display (2) enable cross-origin 14:50:57 Stephen: I would rather we get the platform work done (to allow things to just work) 14:52:13 ..my assumption is "let's assume that on a platform, Chrome cannot query for credentials for a given RP; instead it can only initiate authentication." 14:52:34 ..we need the API before we decide to show the transaction dialog 14:52:44 ..and that's the same API that underlies Conditional UI 14:53:08 John_Bradley: We should get clarity on whether and when it will be implemented. 14:53:57 q? 14:54:17 zakim, close item 2 14:54:17 agendum 2, Update on issue 157: Cross-origin use of credentials, closed 14:54:20 I see 4 items remaining on the agenda; the next one is 14:54:20 3. Any feedback on UA string reduction from payments community? [from Ian] 14:54:23 zakim, take up item 3 14:54:23 agendum 3 -- Any feedback on UA string reduction from payments community? -- taken up [from Ian] 14:54:36 -> https://www.w3.org/2022/01/20-wpwg-minutes.html#t04 January discussion of string reduction 14:54:55 Stephen: Starting in Chrome 101 (in 2 weeks) we will no longer server minor version of the Chromium version (will be all zeros) 14:55:04 ...there are subsequent stages of reduction throughout 2022 14:55:17 ...will remove desktop version number 14:55:46 ...client hint API is being introduced to get the information (but proactive v. passive) 14:56:19 See the antifraud use cases https://github.com/antifraudcg/proposals/blob/main/use-cases/use-cases.md 14:56:26 https://github.com/antifraudcg/proposals/ 14:56:31 q+ 14:56:36 https://github.com/antifraudcg/proposals/issues 14:56:56 ack jean 14:57:03 jeanluc: This is an important topic 14:57:17 ...lots of antifraud providers exploit this information (e.g., UA string) 14:57:47 zakim, close this item 14:57:47 agendum 3 closed 14:57:48 I see 3 items remaining on the agenda; the next one is 14:57:48 4. SPC demos [from Ian] 14:58:12 zakim, take up item 4 14:58:12 agendum 4 -- SPC demos -- taken up [from Ian] 14:58:21 zakim, close item 4 14:58:21 agendum 4, SPC demos, closed 14:58:22 I see 2 items remaining on the agenda; the next one is 14:58:22 5. Next meeting - remote 3-5 May [from Ian] 14:58:28 zakim, take up item 5 14:58:28 agendum 5 -- Next meeting - remote 3-5 May -- taken up [from Ian] 14:58:32 No meeting 28 April 14:58:38 zakim, close item 5 14:58:38 agendum 5, Next meeting - remote 3-5 May, closed 14:58:39 I see 1 item remaining on the agenda: 14:58:39 6. TPAC 2022 [from Ian] 14:58:47 https://github.com/w3c/webpayments/wiki/Remote-Agenda-202205 14:59:44 zakim, close item 5 14:59:44 agendum 5, Next meeting - remote 3-5 May, closed 14:59:45 I see 1 item remaining on the agenda: 14:59:45 6. TPAC 2022 [from Ian] 14:59:48 zakim, take up item 6 14:59:48 agendum 6 -- TPAC 2022 -- taken up [from Ian] 15:00:36 zakim, make minutes 15:00:36 I don't understand 'make minutes', Ian 15:00:42 RRSAGENT, make minutes 15:00:42 I have made the request to generate https://www.w3.org/2022/04/14-wpwg-minutes.html Ian 15:00:45 RRSAGENT, set logs public 15:37:15 jcemer has left #wpwg