14:58:38 RRSAgent has joined #wpwg 14:58:39 logging to https://www.w3.org/2022/11/10-wpwg-irc 14:58:51 Meeting: Web Payments Working Group 14:59:02 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20221110 14:59:06 Chair: Nick 14:59:13 Scribe: Ian 14:59:39 present+ Ian 14:59:43 present+ Clinton_Allen 14:59:47 JeanLuc has joined #WPWG 14:59:54 present+ Jean-Luc_Di_Manno 14:59:56 present+ Doug_Fisher 15:00:05 present+ Gerhard_Oosthuizen 15:00:22 Gregoire has joined #WPWG 15:00:55 present+ Stephen_McGruer 15:01:04 present+ Erhard_Brand 15:01:08 present+ Rolf_Lindemann 15:01:15 present+ Jean-Michel_Girard 15:01:23 present+ 15:01:36 Rolf has joined #wpwg 15:01:45 present+ Steve_Cole 15:01:51 present+ Christian_Aabye 15:01:53 JMGirard has joined #wpwg 15:01:57 present+ Gregoire_Leleux 15:02:09 present+ Arno_van_dr_Merwe 15:02:33 SuzieAS has joined #wpwg 15:02:56 present+ Rouslan 15:03:00 present+ Ryan_Watkins 15:03:06 present+ Arman 15:03:15 present+ Suzie_Annezo-Sebire 15:03:33 present+ 15:03:34 benoit has joined #wpwg 15:03:42 present+ Carey_Ferro 15:03:59 present+ 15:04:24 present+ Vincent_Kuntz 15:04:59 -> https://github.com/w3c/webpayments/wiki/Agenda-20221110 Agenda 15:05:08 ChristianA has joined #wpwg 15:05:19 rouslan has joined #wpwg 15:05:19 Steve_C_ has joined #wpwg 15:05:25 cferro has joined #wpwg 15:05:46 -> https://docs.google.com/presentation/d/1Dq2M1k0L5KhTSwFKvUYb-nd39-7y5M3naVD812_w6jk/edit?usp=sharing Stephen's Slides 15:06:04 vkuntz has joined #wpwg 15:06:05 Topic: FedCM 15:06:24 smcgruer_[EST]: FedCM may have applications to payments in terms of user recognition. 15:06:32 present+ 15:06:46 ...this story starts with the tracking issue that is enabled by cookies 15:07:10 Dougf has joined #wpwg 15:07:23 ...browsers changing to avoid tracking without the user's permission or awareness 15:08:01 ...we are getting rid of 3p cookies so need to find alternatives for well-known use cases such as federated login 15:08:43 ...aggregation of logins in identity providers (IDP) 15:08:53 ...simplifies life for web sites who can hand over login to IDPs 15:09:15 ...there are downsides to current approaches (not part of today's discussion) 15:09:32 ...seamless federated login as practiced today relies on 3p cookies 15:10:01 ...RP.com reached out to idp.com who keeps track of login state...but in a 3p context 15:10:21 ...the emerging solution is FedCM: browser mediates the identity discussion 15:10:30 ...the site lists supported IDPs. 15:10:54 ..the browser goes to the IDPs without telling the IDPs why it's asking. The IDP can access cookies in a 1p context. 15:11:16 ...the IDP can tell the browser what accounts the IDP knows. 15:11:55 ...the browser can display these choices to the user (without showing merchant yet) and allow the user to consent to identify themselves (via browser UX) 15:12:12 ...after the user selects an identity, there are other flows between the RP and IDP (not discussed here). 15:12:16 ...summary: 15:12:40 * The browser enforces isolation, which allows IDP to access 1p cookies. The IDP does not know who is asking. 15:12:59 * There is a privacy issue - what happens if there is *no account*? 15:13:23 ...right now they are not showing the user any dialog if there are no accounts, and they are also not telling the merchant site. 15:13:31 ...perhaps in the future there might be an SPC-like failure screen 15:13:46 [We see UX] 15:14:02 present+ Fahad 15:14:06 present+ Mike_Horne 15:14:19 [Status] 15:14:35 * Single-IDP option-UX shipping in Chrome 108 15:14:47 * Spec is in development in the FedIDCG 15:14:56 * Two other browser vendors have indicated support for this publicly 15:15:06 * There are things not yet implemented 15:15:16 - Auto sign-in for returning users (but 1p cookies could be use) 15:15:26 - Multi-IDP support....early discussions are happening 15:15:44 - Handling not-signed-in IDPs not yet supported 15:16:00 - Work still happening on UX 15:16:05 [What about payments] 15:16:28 smcgruer_[EST]: FedCM will always require user understanding and consent...and returning flows will at least show the user something 15:16:34 ..but I think FedCM could still be useful 15:16:45 ..e.g., PSPs that offer a service across merchants 15:17:00 ...or banks/PSDs wanting to authenticate the user without redirect/popup 15:17:11 [Demo of FedCM with SRC] 15:17:45 q+ 15:18:52 q+ 15:18:56 ack me 15:19:03 q+ 15:19:11 ack nick 15:19:28 ack Gerhard 15:19:41 Gerhard: Really interesting; gives me a payment handler kind of feeling 15:19:53 ...the little window that popped up...is that a 1p iframe? 15:19:57 ..is the size changeable? 15:20:19 smcgruer_[EST]: That iframe in my demo is opened by Visa (3p) 15:20:22 q+ 15:20:30 Fahad has joined #wpwg 15:21:03 Gerhard: What identifier is passed back? 15:21:11 Fahad_ has joined #wpwg 15:21:37 smcgruer_[EST]: The merchant passes a list of IDPs to the browser 15:21:42 q+ 15:21:49 ..the browser talks to each SRC system (with cookies) 15:21:57 ..those SRC systems are asked to return "list of accounts" 15:22:11 ...so for my demo I provided card list rather than login names 15:22:16 q+ 15:22:32 q+ 15:22:51 smcgruer_[EST]: What the user cannot see is that there's a token associated with what the user selects (e.g., some user identifier that enables the rest of the flow) 15:23:05 Gerhard: There's no requirement to do any other UX after the FedCM. 15:23:07 smcgruer_[EST]: Correct 15:23:36 ack JeanLuc 15:24:23 rouslan_ has joined #wpwg 15:24:29 q+ 15:24:31 JeanLuc: Thanks for this presentation. The demo basically shows the browser as an SRC-I. Could you use FedCM instead as an alternative to the recognition domain? 15:24:51 smcgruer_[EST]: You could take the more "traditional" view of FedCM -- you could simply present the user's SRC identity (e.g,. my email address). 15:25:07 ...any SRC system that has a cookie in its domain could send back that identity. 15:25:30 ...one issue here is that you might of N identical identities in this case, and there is no de-duplication function here. 15:25:52 ...so maybe there's a way with FedCM to tell the browser "where you see identical strings, just pick any one" 15:26:01 JeanLuc: Very interesting 15:26:05 ack nicktr 15:26:10 q- 15:26:16 nicktr: Really cool. 15:26:26 ...can you call FedCM from inside of a payment handler 15:26:46 smcgruer_[EST]: Technically there's no reason you couldn't...but I don't know what will happen in mobile windows 15:26:51 ack me 15:27:39 Ian: How is privacy handled in passing of IDP info? 15:27:53 smcgruer_[EST]: Domain only. Probably a .well-known 15:30:27 q? 15:30:30 ack Fahad_ 15:31:37 Fahad_: For multi-IDP there might be different ways to de-dup, e.g., "stop as soon as you find one" 15:31:51 present+ Manish_Garg 15:32:21 smcgruer_[EST]: Multi-IDP is very early stage exploration; this would be good feedback to the FedIDCG 15:32:40 ...my idea for this is that there would be a deduplication field. The browser shows only one. 15:33:11 Fahad_: What happens when the user returns to RP.com? 15:33:20 smcgruer_[EST]: With FedCM today, the user would have to choose to continue. 15:33:40 ...RP.com could put a first party cookie; that's feasible but there are downsides 15:33:56 ...it would be good to engage with the CG on returning user flow 15:34:15 ...we'd probably tell the user "you are being logged in" rather than doing it silently 15:34:37 Fahad_: The spec has a client id. When the IDP returns info they talk about "already approved client id" 15:34:51 present+ Praveena 15:35:11 smcgruer_[EST]: The IDP could lie and that would lead to tracking silently 15:35:39 ..but I personally think that if a user comes back to a site where the user has previously used FedCM, the site should be able to trivially get back identity via FedCM 15:35:55 Fahad_: In the browser UX .. is the IDP name set by RP.com? 15:36:03 ...can multiple IDPs have the same display name? 15:36:11 smcgruer_[EST]: The IDPs are represented by their origin 15:36:29 Fahad_: We were interested with "Sign in with click to pay" 15:37:27 Topic: SPC use cases 15:37:45 [Gerhard slides] 15:38:31 [Progress so far] 15:38:51 Gerhard: Both Open Banking and 3DS support more than just single transaction. What might we do next with SPC? 15:40:13 [we look at current fields displayed by SPC transaction dialog, primary use case, and primary authentication approach] 15:40:34 Gerhard: We'd like to start here discussion of next use cases for SPC 15:40:36 q? 15:41:06 Gerhard: I can see three axes for extension -- (1) additional display fields (2) new use cases/transactions (3) other forms of authentication 15:41:34 I have made the request to generate https://www.w3.org/2022/11/10-wpwg-minutes.html Ian 15:41:41 I'm logging. Sorry, nothing found for 'who's here' 15:41:54 I'm logging. Sorry, nothing found for 'who's here' 15:43:14 clinton2 has joined #wpwg 15:43:21 Gerhard: there are some additional UX topics (not part of my 3 categories above) - opt-out, icon size 15:44:02 [Trusted merchant list] 15:44:10 Gerhard: "Trust this merchant" in the display. 15:44:16 ...another one is "Trust this device" 15:44:47 q+ 15:45:10 Gerhard: Imagine we are doing this in open banking...the user journey would start with "pay with my bank" 15:45:14 ..there would be a redirect to the bank 15:45:25 ...the SPC confirmation could happen in that context, followed by a redirect 15:45:30 ...do we need a redirect capability 15:47:08 Ian: How does this relate to SPC? 15:48:20 Gerhard: Want to "trust a merchant"; the user could say essentially "don't do a step up in the future". The issuer could record that information. 15:50:15 Ian: Why does the user's view matter? 15:50:24 Gerhard: It's part of EMVCo requirement 15:50:29 ...to offer this option 15:51:08 q+ 15:51:11 ack me 15:51:12 ack JeanLuc 15:51:59 JeanLuc: If I understand correctly, the merchant could populate the field without any user validation. 15:52:44 Gerhard: For me, the point is that the SPC display is browser-controlled and thus the merchant can't fake it 15:53:28 JeanLuc: The merchant could attack in the second AREQ 15:55:23 Topic: Charter 15:55:38 https://lists.w3.org/Archives/Public/public-payments-wg/2022Nov/0000.html 15:56:30 https://www.w3.org/2004/01/pp-impl/83744/join 15:56:41 Topic: Schedule 15:57:09 Next meeting: 8 December 15:57:50 mg has joined #wpwg 15:58:30 Topic: FTF? 15:58:44 +1 (either) 15:58:49 +1 15:58:50 +1 15:58:51 +1 15:58:51 +1 (either) 15:58:52 +1 for a FTF 15:58:53 +1 15:58:55 May is better I think! +1 15:59:00 +1 15:59:01 +1 15:59:11 +1 (may have to be virtual for me) 15:59:21 as long at it does not overlap! 15:59:32 RRSAGENT, make minutes 15:59:32 I have made the request to generate https://www.w3.org/2022/11/10-wpwg-minutes.html Ian 15:59:36 RRSAGENT, set logs public 15:59:38 arman has joined #wpwg 16:00:16 cferro has left #wpwg 16:00:18 mg has left #wpwg 16:01:36 Gerhard has left #wpwg 16:02:17 Gregoire has left #wpwg 18:00:10 Zakim has left #wpwg