14:58:43 RRSAgent has joined #wpwg 14:58:47 logging to https://www.w3.org/2023/02/02-wpwg-irc 14:59:29 Anne has joined #wpwg 14:59:33 present+ 14:59:41 present+ Omer-Talha_Ozdemir 14:59:53 present+ Franck_Delache 15:00:03 present+ Stephen_McGruer 15:00:13 present+ Anne_Pouillard 15:00:40 regrets+ NIck_Telford-Reed 15:01:06 fdelache has joined #wpwg 15:01:13 Meeting: Web Payments Working Group 15:01:19 Chair: Ian 15:01:26 present+ Adrian_Hope-Bailie 15:01:32 present+ Jean-Luc_di_Manno 15:01:38 present+ Gregoire_Leleux 15:01:39 present+ Nick_Burris 15:01:43 clinton has joined #wpwg 15:01:53 present+ Jean-Michel_Girard 15:01:54 present+ Sameer_Tare 15:02:13 present+ Rouslan_Solomakhin 15:02:15 Gregoire has joined #WPWG 15:02:26 present+ Doug_Fisher 15:02:41 benoit has joined #wpwg 15:02:52 present+ Steve_Cole 15:03:05 present+ Gerhard_Oosthuizen 15:03:09 present+ Michael_Horne 15:03:13 Gerhard has joined #wpwg 15:03:16 present+ David_Benoit 15:03:21 present+ Fahad_Saleem 15:03:27 present+ Sue_Koomen 15:03:31 AdrianHB_ has joined #wpwg 15:04:01 present+ Anthony_Evans 15:04:24 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20230202 15:04:28 JeanLuc has joined #WPWG 15:04:44 Topic: Fynbos Update 15:04:56 Sue has joined #wpwg 15:04:59 present+ Clinton_Allen 15:05:07 JM_Girard has joined #wpwg 15:05:09 present+ Rick_Byers 15:05:21 AdrianHB: Omer is a colleague working on SPC experiments; we'll look at those today 15:05:23 scribe: Ian 15:06:13 AdrianHB: Since stepping down as co-Chair I've been working at Fynbos on a digital wallet; we are live this week in beta in the US 15:06:30 ...one of the main features we include are "payment pointers" 15:06:48 ...our hypothesis is that we need a better way to refer to accounts 15:07:35 ...payment pointers are really just URLs (a subset of them) 15:07:47 ...payment pointers need to use HTTPS and have a path component 15:08:01 ...we have a shortened form of it that makes them easier to use 15:08:26 ...the URL is the entry point for interacting with the wallet 15:08:49 ...payment pointers use content negotiation; apps can use them or they can be used in a browser directly 15:09:09 ...e.g., bank allows user to create a "payment request' and they get a payment pointer they can use 15:09:47 ...we have an authorization protocol on top of the APIs called GNAP (a successor to Oauth2; developed by same folks; currently in last call at the IETF; expect it to be finalized in the next few months) 15:09:53 SameerT has joined #wpwg 15:09:57 ...it's a nice way to use OAuth for authorization 15:09:59 present+ 15:10:05 ...we've defined an extension to GNAP for SPC 15:10:29 ...GNAP lets you send a request to a server and request a grant; the authorization service lets you select an authentication mechanism. 15:10:36 ...the one written into the spec is a redirect. 15:10:48 ...there are also possibilities to do app redirects 15:11:13 ...GNAP useful to access open payment APIs 15:11:25 ..SPC fits nicely into GNAP 15:11:33 ...Omer is writing up a spec based on the work he's done 15:11:50 ...so suppose I've been given a card number and a payment pointer by my bank 15:11:59 ...I can just enter my payment pointer 15:12:09 ...the merchant will initiate interaction on the backend with my wallet. 15:12:45 ...the wallet, for example, can redirect me to a site to share some personal information that is part of a single consent 15:13:08 present+ Holger_Kunkat 15:13:09 Love the single unified consent, something I've argued we need to be guiding the web towards! 15:13:43 [Basic Flow slide] 15:14:04 Adrian: After authentication, issuer gives a token back to Shopify to execute the payment 15:14:52 ...one example we've been thinking about is where a wallet executes a card payment, but rather than doing a follow-on authorization, the authorization happens up front. The token is exchanged for a (tokenized) card on the backend after the authorization has been completed. 15:15:10 ...so the issuer authorizes the payment, then gets the access token later from the acquirer 15:15:22 Dfisher has joined #wpwg 15:15:38 [Video of using SPC] 15:16:38 Adrian: In the demo, there's no redirect. The user types in a payment pointer; the bank gives credential IDs to the merchant who triggers SPC; the merchant sends the assertion back and the issuer returns an access token 15:16:59 Adrian: Next steps would be to experiment with eCommerce with tokenized cards 15:17:20 ..the payment pointer becomes a way to initiate a negotiation; but the actual payment rail (backend) does not change 15:17:47 ...Open Payment APIs are being documented as formal spec and updated to support multiple payment methods 15:18:55 ...our focus has been on the user experience 15:19:05 ...we've sought to push complexity to the backend 15:19:24 ...normally when you do a delegated authentication it's hard to avoid front-channel interactions 15:19:36 ...but we've been trying to move those interactions to the back channel 15:19:41 [Second demo] 15:21:16 q+ 15:21:34 ack me 15:21:49 rouslan has joined #wpwg 15:21:53 q+ 15:21:54 q+ 15:22:13 q+ 15:22:39 q+ to ask about similarity between CC #s and payment pointers, re: are browsers expected to autofill those, keep it in settings, or pass it through some API? 15:22:47 Anthony: Love it. Given open banking in the UK running Oauth2, what would the transition be from Oauth2 to new protocols? 15:23:12 Adrian: If you look at the GNAP spec, there's a section mapping to Oauth2. There was an early design decision regarding transition and compatibility 15:23:37 ...even if you didn't switch to GNAP, this is not a bad reference to show how easily you can bring in SPC 15:23:42 present? 15:23:55 ...you need to (1) identify whom to speak to to get credentials and (2) get the credentials 15:24:03 I'm logging. Sorry, nothing found for 'who's here' 15:24:53 q+ 15:25:21 Ian: Suggest using FedCM to get the payment pointer 15:25:26 Adrian: Or a payment handler 15:25:40 ...e.g., payment handler without UI 15:26:14 q? 15:26:16 ack me 15:26:17 ack rbyers 15:26:33 rbyers: I love seeing these simple payment demos with minimal UI. Obviously the typing feels like the one piece left. 15:26:56 ...how confident are you that issuers are ok with this minimal amount of UI. Should we add more to SPC to increase chance of issuers being happen? 15:26:59 s/happen/happy 15:27:07 AdrianHB: It think it depends on the use case 15:27:18 ...for small amounts in e-commerce may be ok 15:27:52 q- 15:28:15 ...we'll have to wait and see, I suppose. We've got a P2P wallet and I suspect will iterate on P2P for the next few months, but e-commerce also on our roadmap 15:28:24 ..if we have positive feedback from partners, we'd be keen to do that. 15:28:29 q+ 15:28:55 ...I'd guess that the UI is the place where the discussion would need to happen. It's the interop domain....but since details are not in specs, we'd need to navigate that carefully. 15:29:15 rbyers: To the extent that people want to adopt, we are open to making changes 15:29:28 AdrianHB: One immediate question form us -- we show the payment pointer 15:29:55 ...but if you were to use something else, like choosing a bank (in open banking) and then an account...I'd probably need to see an institution logo 15:30:04 ...choosing accounts also interesting 15:30:18 ack me 15:30:18 rouslan, you wanted to ask about similarity between CC #s and payment pointers, re: are browsers expected to autofill those, keep it in settings, or pass it through some API? 15:30:33 -> https://github.com/w3c/secure-payment-confirmation/issues/197 Issue 197 on logos 15:30:39 q- 15:30:53 q+ Anthony 15:30:54 ack Sameer 15:30:59 ack me 15:31:14 SameerT: Very interesting concept. I'd like to break down the flow. When the pointer is typed, is the PSP following an interface? 15:31:28 Adrian: The payment pointer is a URL-as-shortcut 15:31:43 ...users could, in theory, also just type in a URL, but we experimented with that and it failed. 15:31:58 ...we want the origin of the account issuer 15:32:07 ...we don't want to redirect through another origin (e.g,. user's email account) 15:32:16 ...URLs also allow redirects. 15:32:42 ...on the backend, then, the PSP sends a request directly to the origin of the URL. The negotiation involves (1) what payment methods are available (2) who is payee / who is payer 15:32:52 ..the way that GNAP works, your requester is basically asking for a _grant_ 15:33:29 ...usually what you get back from GNAP upon receiving a request is a request that the user authorize the grant issuance 15:33:36 ....and then the user authenticates. 15:33:48 q+ 15:34:13 ...so the merchant looks to see if browser supports SPC, then initiates GNAP request with SPC; if fails (e.g., no credentials) can fail silently and the merchant can request a different authentication method 15:34:39 ...then we imagine exchanging an access grant for a card token to initiate the actual payment 15:35:16 ...we are adding extensions to GNAP to support SPC 15:35:34 ...when the client requests grant; the server needs to support SPC and have credentials for the account. 15:36:27 ack Gerhard 15:37:50 q+ 15:38:23 [We review the pre-authorization flow] 15:39:19 Gerhard: Any extension required to SPC? 15:39:40 Adrian: I've been looking at SRC to see if it might replace some SRC-I functionality up front 15:39:58 ..it's a bit difficult knowing in detail what would be the most sensible way to use the token in a card payment 15:40:05 Fahad has joined #wpwg 15:40:15 ...but if issuers are satisfied with raw SPC output, great; but if more data is required we can discuss 15:41:09 q? 15:41:51 Adrian: We could find a way to include data in the merchant's initiate request, and the issuer could say "no strong authentication needed" 15:42:15 Gerhard: Should we explore more interactions with IETF re: SPC as a standard option? 15:42:24 Adrian: We've discussed that with them 15:42:34 ...e.g., having a generic WebAuthn interaction; the reality is we could have both 15:42:48 ...all the modules define in the framework is what data is exchanged 15:42:56 ...issuers and servers will decide which one they want to use 15:43:33 ...another one we've been discussing is an iframe interaction, where the response is just a URL to use for an embedded iframe; the issuer can do more to gather data (a la methodURL) to decide what to do next 15:43:50 ..so first interaction would be "inject iframe"; second would be "step up" 15:44:01 Gerhard: Sounds similar to 3DS merchant app options 15:44:01 q+ 15:44:26 q+ to suggest IETF/W3C chat at April meeting 15:44:55 ack Anthony 15:45:05 ack JeanLuc 15:45:52 JeanLuc: Regarding card-based transactions -- this looks like an alternative to 3DS; however for 3DS there is a proof of authentication that is expected to be re-introduced in the authorization method. I understand this would be an access token 15:46:06 ...but there is no card network token definition for this type of token 15:46:25 Adrian: The access token format is not strictly defined 15:46:35 ..in theory it could be the same as for an ISO 8583 message 15:47:00 ..but I think a more elegant solution would be the token+URL combination from the issuer would be used to make a request to a service and get back what you need for the 8583 message 15:47:08 q+ 15:47:08 ...so there'd be a round trip before authorization request 15:48:23 JeanLuc: So the access token could either be the proof of authentication, or it could be used to fetch relevant data 15:48:43 Adrian: The advantage of the fetch is that you can decouple the systems 15:48:55 ..you could have a separate system that does risk mitigation 15:49:17 ack me 15:49:17 Ian, you wanted to suggest IETF/W3C chat at April meeting 15:49:36 q+ 15:50:30 Ian: Perhaps there are ways to experiment with this protocol...but implemented as 3DS under the hood. 15:50:51 Adrian: Yes, I could see GNAP as an interface atop existing business functions 15:50:55 q? 15:51:01 zakim, close the queue 15:51:03 ok, Ian, the speaker queue is closed 15:51:30 ack clinton 15:52:03 clinton: I think the energy towards recognition to payments is critical for browser-based payments. If we had a longer session on this, it would be great (with issuers, payment networks) 15:52:12 ...this is a great step; feel like we need more time 15:52:22 Ian: +1 to longer session 15:52:24 kudos Adrian .. I echo Clinton's comments that this a huge step forward 15:52:32 ack fahad 15:52:41 ack fdelache 15:52:59 fdelache: How does enrollment work? 15:53:13 ...have you thought about facilitating enrollment? 15:53:53 AdrianHB: I think the enrollment challenge is outside of the payment flow; but I imagine similar flows after ID&V to prompt the user to enroll 15:54:07 ...if the user does not have SPC on the device and are redirected to the issuer; the issuer could enroll the device at that time. 15:56:04 Topic: Autofill 15:56:45 smcgruer_[EST]: Regarding autofill (e.g., used in guest checkout): we've been taking a step back lately and want to work with web developers more on autofill to understand needs 15:56:54 ...in the world of payments in particular 15:57:07 q+ 15:57:54 smcgruer_[EST]: For example, some sites want to disable autofill; we want to understand the use cases 15:57:54 ...and are interested in other issues around autofill. 15:58:08 q+ 15:58:31 google form for comments? 15:58:36 rbyers: We've looked at autofill as a "browser feature" ... developers can see autofill usage; we hope to see more data on how autofill can affect conversion rates 15:59:29 Topic: Extended meeting 15:59:29 Payment industry trends? 15:59:29 PSD3? 15:59:29 Update from open banking colleagues 15:59:50 https://www.irccloud.com/pastebin/DLRDBuJj/ 16:00:46 Sorry: Example code for detecting whether a field was filled with autofill in chromium browsers at least: 16:00:46 el.addEventListener('change', e => { 16:00:46 console.log('change', e, el.closest("input:-webkit-autofill")==el); 16:00:46 }); 16:00:46 Topic: Next meeting 16:00:46 2 March 16:01:14 Fahad has joined #wpwg 16:01:16 RRSAGENT, make minutes 16:01:17 I have made the request to generate https://www.w3.org/2023/02/02-wpwg-minutes.html Ian 16:01:19 fdelache has left #wpwg 16:01:50 RRSAGENT, set logs public 18:00:00 Zakim has left #wpwg 18:57:58 zakim, bye 18:58:00 rrsagent, bye 18:58:00 I see no action items