13:30:43 RRSAgent has joined #wpwg 13:30:47 logging to https://www.w3.org/2023/03/27-wpwg-irc 13:30:55 Meeting: Web Payments Working Group 13:31:11 Agenda: https://github.com/w3c/webpayments/wiki/Remote-Agenda-202303 13:31:15 Chair: Nick 13:31:29 agenda+ Welcome 13:31:35 agenda+ Where we Are 13:31:42 agenda+ Charter issue 13:31:52 agenda+ SPC UX 13:32:38 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 13:42:30 scribe: Ian 13:55:38 present+ 13:57:23 jpMarzetti has joined #wpwg 13:57:43 present+ Stephen_McGruer 13:57:57 clinton has joined #WPWG 13:58:24 present+ Juan_Pablo_Marzetti 13:58:27 present+ Holger_Kunkat 13:58:33 zakim, who's here? 13:58:33 Present: Ian, Stephen_McGruer, Juan_Pablo_Marzetti, Holger_Kunkat 13:58:35 On IRC I see clinton, jpMarzetti, RRSAgent, Zakim, hober, pea1358, canton_, dlehn, benoit, TimCappalli, Github, npd, smcgruer_[EST], rowan_m, ljharb, Travis, tobie, hadleybeeman, 13:58:35 ... rbyers, Dongwoo, nicktr, slightlyoff, weiler, jeffh, wanderview, Ian 13:58:47 present+ Giorgio_Mazzucchelli 13:59:52 present+ Carey_Ferro 13:59:55 present+ Anne_Pouillard 14:00:12 cferro has joined #wpwg 14:00:12 Takashi has joined #WPWG 14:00:14 Anne has joined #wpwg 14:00:16 present+ Jean_Luc_di_Manno 14:00:20 JeanLuc has joined #WPWG 14:00:26 present+ Chris_Bohatka 14:01:00 present+ Derek 14:01:06 present+ Bastien_Latge 14:01:11 Gerhard has joined #wpwg 14:01:16 present+ Gerhard 14:01:23 present+ Harjender 14:01:26 present+ Bryan_Penny 14:01:31 present+ Tony_England 14:01:38 present+ Vasilii 14:02:16 present+ Steve_Cole 14:02:21 present+ Solai 14:02:25 present+ Haribalu 14:02:28 gmz has joined #wpwg 14:02:36 present+ Doug_Fisher 14:02:36 TonyE has joined #wpwg 14:02:57 present+ Nick_Burris 14:03:00 present+ Praveena 14:03:06 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 14:03:14 present+ Clinton_Allen 14:03:17 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 14:03:24 HKU has joined #wpwg 14:03:24 zakim, who's here? 14:03:24 Present: Ian, Stephen_McGruer, Juan_Pablo_Marzetti, Holger_Kunkat, Giorgio_Mazzucchelli, Carey_Ferro, Anne_Pouillard, Jean_Luc_di_Manno, Chris_Bohatka, Derek, Bastien_Latge, 14:03:25 ... Gerhard, Harjender, Bryan_Penny, Tony_England, Vasilii, Steve_Cole, Solai, Haribalu, Doug_Fisher, Nick_Burris, Praveena, Clinton_Allen 14:03:25 On IRC I see HKU, TonyE, gmz, Gerhard, JeanLuc, Anne, Takashi, cferro, clinton, jpMarzetti, RRSAgent, Zakim, hober, pea1358, canton_, dlehn, benoit, TimCappalli, Github, npd, 14:03:25 ... smcgruer_[EST], rowan_m, ljharb, Travis, tobie, hadleybeeman, rbyers, Dongwoo, nicktr, slightlyoff, weiler, jeffh, wanderview, Ian 14:03:32 present+ Nick_Telford-Reed 14:03:53 present+ Christian_Aabye 14:03:59 Solai has joined #wpwg 14:04:04 present+ Gokhan_Tekkaya 14:04:21 present+ Takashi 14:04:41 present+ Mike_Horne 14:05:35 present+ Sameer_Tare 14:05:55 present+ Tomasz_Blachowicz 14:06:36 Bryan_Penny has joined #wpwg 14:06:37 zakim, take up item 1 14:06:37 agendum 1 -- Welcome -- taken up [from Ian] 14:06:44 I didn't see my name on the "present+ " messages but it was mentioned by RRSAgent. Does it make a difference? 14:06:54 SameerT has joined #wpwg 14:06:54 zakim, who's here? 14:06:55 Present: Ian, Stephen_McGruer, Juan_Pablo_Marzetti, Holger_Kunkat, Giorgio_Mazzucchelli, Carey_Ferro, Anne_Pouillard, Jean_Luc_di_Manno, Chris_Bohatka, Derek, Bastien_Latge, 14:06:58 ... Gerhard, Harjender, Bryan_Penny, Tony_England, Vasilii, Steve_Cole, Solai, Haribalu, Doug_Fisher, Nick_Burris, Praveena, Clinton_Allen, Nick_Telford-Reed, Christian_Aabye, 14:06:58 ... Gokhan_Tekkaya, Takashi, Mike_Horne, Sameer_Tare, Tomasz_Blachowicz 14:06:58 On IRC I see SameerT, Bryan_Penny, Solai, HKU, TonyE, gmz, Gerhard, JeanLuc, Anne, Takashi, cferro, clinton, jpMarzetti, RRSAgent, Zakim, hober, pea1358, canton_, dlehn, benoit, 14:07:02 ... TimCappalli, Github, npd, smcgruer_[EST], rowan_m, ljharb, Travis, tobie, hadleybeeman, rbyers, Dongwoo, nicktr, slightlyoff, weiler, jeffh, wanderview, Ian 14:07:12 -> https://www.w3.org/Consortium/Legal/2017/antitrust-guidance Antitrust guidance 14:07:22 NickTR: Welcome all 14:07:37 AdrianHB_ has joined #wpwg 14:07:46 present+ Nick_Burris 14:07:53 dfisher has joined #wpwg 14:08:10 NickTR: Please review antitrust guidance and good conduct docs. 14:08:20 ChristianAabye has joined #wpwg 14:08:27 [Nick does overview of the Agenda https://github.com/w3c/webpayments/wiki/Remote-Agenda-202303 ] 14:08:44 vt_ has joined #wpwg 14:09:04 present+ Sue_Koomen 14:09:13 vasilii has joined #wpwg 14:09:13 q+ 14:10:32 ack kme 14:10:38 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 14:10:44 zakim, close item 1 14:10:44 I see a speaker queue remaining and respectfully decline to close this agendum, Ian 14:10:44 ack me 14:10:44 zakim, close item 1 14:10:45 agendum 1, Welcome, closed 14:10:45 I see 3 items remaining on the agenda; the next one is 14:10:45 2. Where we Are [from Ian] 14:10:49 zakim, take up item 2 14:10:49 agendum 2 -- Where we Are -- taken up [from Ian] 14:11:06 -> https://drive.google.com/file/d/1-bV6lAq3EsECqgpJkp-sEzZeEJ3tTd98/view?usp=share_link Nick slides 14:11:08 present+ AdrianHB 14:11:30 omertoast has joined #wpwg 14:11:46 [Ian will not minute most of what Nick covers in slides] 14:11:57 [But will type highlights] 14:12:08 NickTR: Congrats on PR API to Recommendation (Q4 2022) 14:12:37 present+ Ömer_Talha_Özdemir 14:13:22 NickTR: Thanks also to Gerhard and Praveena as of rechartering! 14:15:14 NickTR: W3C now an incorporated non-profit (no longer MIT project) 14:19:12 q: There's no active work on payment handler. Is there a desire/need to explore the group's view on this, and explore how we can roll this out further? 14:19:36 NickTR: I think SPC is genuinely solving a problem that has not been previously solved. 14:20:40 Bastien has joined #WPWG 14:21:21 NickTR: Horizontal review is nearly completed; awaiting privacy review 14:22:00 ...once we have addresses any issues, we can advance to Candidate Recommendation 14:23:02 NickTR: Will look forward to more pilot results at TPAC (in September, in Seville) 14:23:36 NickTR: PIX growth is phenomenal; will be very interesting to hear more about that 14:23:48 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 14:25:15 zakim, close this item 14:25:15 agendum 2 closed 14:25:16 I see 2 items remaining on the agenda; the next one is 14:25:16 3. Charter issue [from Ian] 14:25:20 zakim, take up item 3 14:25:20 agendum 3 -- Charter issue -- taken up [from Ian] 14:25:43 https://github.com/w3c/webpayments/issues/262 14:26:23 present+ Gustavo 14:27:19 PROPOSED: Restore text in charter 14:27:22 +1 to restore 14:28:02 gkok has joined #wpwg 14:28:21 Can we wait to hear from Tess on the issue before we make a resolution in the WG? 14:28:34 praveenas_ has joined #wpwg 14:28:56 AdrianHB_: I'd like to understand the motivation for the request before we resolve this 14:29:07 q+ 14:29:11 ack clinton 14:29:12 q+ 14:30:28 Clinton: The language is "user agent specifics" 14:30:32 Derek has joined #wpwg 14:31:01 q+ 14:31:01 q+ to say that we risk preventing ourselves from writing a spec that can be adopted under certain legal regimes 14:31:49 smcgruer_[EST]: Payment journeys are very user-focused, including visual elements (plus accessibility); I understand why complicated 14:31:50 q? 14:31:51 ack nicktr 14:31:52 ack nicktr 14:31:53 q? 14:32:43 nicktr: What level of review? 14:32:45 Ian: Full review 14:32:56 Gerhard: It sounds like a lot of work. 14:33:07 (Ian: It is but mostly for me :) 14:33:48 Gerhard: The way I read the text it allows us to do SPC provided we stay general about display of fields 14:33:58 ...also good to leave room for competition among browsers 14:34:29 ...I don't think our spec is overly prescriptive 14:34:49 ...since it was in the charter previously, seems ok to add back 14:35:05 ack adr 14:35:05 AdrianHB_, you wanted to say that we risk preventing ourselves from writing a spec that can be adopted under certain legal regimes 14:35:07 ack 14:35:13 ack Gerhard 14:35:22 AdrianHB_: (1) It is a lot of work and there's a risk of derailing the charter. 14:36:39 q+ 14:37:37 AdrianHB: I am concerned language restricting discussion of UI may prevent us from doing some work 14:37:41 ack me 14:37:52 present+ 14:38:30 Sue has joined #wpwg 14:39:45 NickTR: The proposal is not carried. 14:39:54 ...we'll wait for Apple to provide more information 14:40:11 ACTION: Ian to work with Chairs to reach out to Apple to understand more from them 14:40:33 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 14:40:56 q? 14:41:01 zakim, close this item 14:41:01 agendum 3 closed 14:41:38 I see 1 item remaining on the agenda: 14:41:38 4. SPC UX [from Ian] 14:41:38 zakim, take up item 4 14:41:38 agendum 4 -- SPC UX -- taken up [from Ian] 14:41:38 -> http://www.w3.org/2023/03/spc-fallback.pdf Fallback UX slides 14:42:18 [Ian presents slides] 14:43:08 present+ Vasilii_Trofimchuk 14:43:27 ian: responding to feedback from Tomasz, Stephen and I have worked on a potential improvement to the flow of SPC 14:44:12 q+ Does SPC support all the Passkey functionality, or are we still bound to the 'SPC is only available in the browser it was created'? 14:44:13 [background considerations] 14:45:00 ian: WebAuthn privacy requirements 14:45:27 ...Don't want link to arbitrary page from secure UX 14:45:39 [Current Situation] 14:46:04 [New behaviour] 14:46:34 q+ 14:46:35 ian: User gets full transaction information whether there are matching credentials or not 14:47:26 ...we propose introducing a new signal (authenticate another way and no matching credentials both send same signal) 14:47:51 ack Gerhard 14:48:06 Gerhard: I like this approach 14:49:10 ian: perceived benefits: no leakage about no matching credentials, new signal continue v cancel, easier to understand the UX 14:50:01 Gerhard: If credential id is not present, will the user know? 14:50:36 Stephen: the user does not know. What should be communicated to user is an open questions 14:50:53 ...it could be based around "passkey" 14:51:12 q+ to get user research about how user's react to "no match" screen if they have become familiar with the verification flow (i.e. biometric is coming next) 14:52:16 Gerhard: as an implementer, we don't know whether the credentials are there, and so we might send (for example) an OTP, when the user simply wants to cancel the transaction 14:52:21 Gerhard: I like this because the signal is now clearer between "cancel" and "continue" 14:52:25 ...so this proposal is an improvement 14:53:05 ...but it's my understanding that the user has to be in the same browser instance 14:53:29 Stephen: that's true. On Android, there is full integration to include passkey 14:53:47 ...on Windows, there's a potential path to implementation of something similar 14:54:04 ...it's not clear what the pathway is in the Apple ecosystem 14:54:32 Gerhard: We really need the passkey piece - without that, the UX would be strongly suboptimal 14:54:38 Gerhard: +1 to this enhancement 14:54:55 ...would be nice to be explicit to user about "no passkeys available" 14:54:59 ...I would like to give users a hint about passkey if we can 14:55:11 q? 14:55:29 Gerhard: Could you dispense with the "Confirm" button on the fallback? 14:55:34 ack AdrianHB_ 14:55:34 AdrianHB_, you wanted to get user research about how user's react to "no match" screen if they have become familiar with the verification flow (i.e. biometric is coming next) 14:55:53 AdrianHB_: this is an improvement 14:56:33 AdrianHB: Risk that user does not understand that "confirm" will involve MORE AUTH rather than "just payment" 14:56:38 ...but my concern is that as a user, when I've got used to using this, but I get the "confirm" dialogue, I am not sure what will happen next 14:56:49 ...so I'd like to see user experience research 14:57:13 q? 14:57:14 q+ 14:57:29 AdrianHB_: Should be clearer "Please confirm details; we will authenticate you after you do" 14:57:29 q+ 14:57:41 ...the message should be explicit about the authentication not being built in in the "confirm" flow 14:57:44 ack smcgruer_[EST] 14:57:44 q? 14:57:54 smcgruer_[EST]: I agree 14:58:16 ...one idea might be to give the caller to specify their fallback authentication 14:58:21 smcgruer_[EST]: One idea we had was to give the caller some way to specify what the fallback might look like, e.g., "Otherwise I'm going to do SMS/OTP" 14:58:25 Comment on that 14:58:31 q? 14:58:31 q+ Gustavo 14:58:37 ack Ger 14:58:40 Gerhard: 14:59:19 Gerhard: what if we say "would you still like to authenticate"? 14:59:29 Gerhard; What if "Authenticate a different way" is the same link in the fallback, and only a "Cancel" button ? 14:59:42 +1 Ian/Stephen - a hint as to the way auth will be done after this confirm screen sounds like an idea worth exploring 14:59:43 ...so consistency with location and meaning of that "other way" link 14:59:58 q? 15:00:28 smcgruer_[EST]: We should not go too deep into the specifics of the UX :) 15:00:41 smcgruer_[EST]: this takes us exactly into the space we were discussing in the context of the charter text 15:00:59 ian: nobody is saying "it must work this way" 15:01:13 q+ 15:01:14 q? 15:01:18 ack Gustavo 15:01:22 Gerhard: we should limit ourselves to events 15:02:01 Gustavo: Typically, issuer (not merchant) determines next authentication method 15:02:08 gustavo: as a merchant, I don't control what happens next - the ASPSP defines the fallback 15:02:25 ...perhaps we should have an enumeration of the possible fallbacks? 15:02:32 q? 15:02:33 Gustavo: not sure about "Confirm" button 15:02:35 perhaps it's better to use "continue" versus "confirm" 15:02:52 +1 on Gustavo's comment 15:03:33 clinton: can we make requirements of the UX without saying what the UX should be 15:04:28 smcgruer_[EST]: the spec can't require how it looks - it can talk about flows 15:04:43 q? 15:04:46 ack clinton 15:05:11 NickTR: Difference here between W3C specs and EMVCo specs (which have more specific UX requirements) 15:05:26 q+ 15:05:28 q+ 15:05:55 ack Gerhard 15:05:55 q+ 15:06:13 q+ 15:06:27 Gerhard: is it allowed to say "these fields must/should be displayed"? 15:06:34 https://w3c.github.io/secure-payment-confirmation/#sctn-transaction-confirmation-ux 15:06:41 "To avoid restricting User Agent implementation choice, this specification does not require a User Agent to display a particular user interface when PaymentRequest.show() is called" ... 15:06:53 "However, ... the User Agent MUST ensure that the following is communicated to the user and that the user’s consent is collected for the authentication:" 15:07:03 "The payeeName if it is present., The ..." 15:07:32 Thanks smgruer! 15:07:37 q? 15:07:55 queue=dfisher, gkok, Ian 15:07:59 ack dfisher 15:08:24 dfisher: I think the "Confirm" could serve a useful purpose and might even lead to a frictionless UX 15:08:34 ...that the user confirmed the details of the purchase. 15:08:59 q+ to note that you can't prove this 15:09:29 q+ 15:09:42 Ian: The bank can't validate what was shown 15:09:56 +1 dfisher - Would be even better if the browser could provide some extra context in the response that might solve some of the frictionless flow risk assessment data requirements. Is this a scenario when the browser would be okay providing a unique device ID? 15:10:07 q- 15:10:29 Ian: Rather, if Issuer does SPC, they know; but if merchant does it no proof. 15:11:02 ...so interesting frictionless open when bank calls SPC 15:11:03 q- 15:11:04 ack gkok 15:11:24 Gustavo: I would also be intrigued if issuers were more comfortable with frictionless if they knew what the user saw. 15:11:51 ...if you had something like the no matching credentials windows and were more explicit about no matching passkeys in that window, 15:12:32 ...I think that number of passkey users will be initially small, so the fallback UI will be more prevalent to a larger number of users 15:12:40 ...and so this UX needs to be really clear for the majority of users 15:12:43 q? 15:12:46 ack me 15:13:52 question: Always willing to discuss 'frictionless' flows and scenario's on Wednesday too? 15:14:13 smcgruer_[EST]: If we did the UX on the right, would that change adoption status and, is it sufficient? 15:14:36 ...I'd love to have a partner to origin trial this 15:14:51 Is it possible that the "Confirm" screen could post a 1st-party request to the RP in the background to facilitate frictionless? 15:15:02 q+ 15:15:02 q? 15:15:12 q+ 15:16:06 q+ 15:16:11 Gerhard: I think it would be a terrible experience if the user wants to cancel and we continue to try to authenticate them. so I think this is a significant improvement. 15:16:35 smcgruer_[EST]: I don't disagree with you; the scenario we envisage today is that the user has pushed "pay" to begin with 15:16:47 q+ 15:17:30 ack Gerhard 15:18:24 Gerhard: There are cases where the user "wants to go back" and so "cancel" is an important option 15:18:26 q? 15:18:29 ack prove 15:19:22 Praveena: I agree with the above comments. To get significant data, we need more of the ecosystem ready; so there's value in getting something out there. 15:19:23 ack Gus 15:19:26 ack prav 15:19:29 ack gkok 15:19:30 ack gkok 15:19:52 Gustavo: I am interested in the idea where the user has a better sense of what happens next. 15:20:07 ...I'd be happy to help sketch out the scenarios 15:20:25 ...it should be possible to say "cancel" (and that happens in 3DS frames) 15:20:51 ...for the nuanced topics (confirm/continue), it would be valuable to sketch out the exact user journeys to inform those discussions 15:20:52 q? 15:21:12 +1 on Gustavo's comments, also happy to help there. 15:21:13 ACTION: Gustavo to help describe user journeys for continuing 15:21:17 ack JeanLuc 15:22:46 JeanLuc: In 3DS, an issuer may guess whether the user has confirmed. When the issuer decides to launch SPC, they already know that there's a credential registered. 15:22:48 q+ 15:22:57 (Ian: but they don't know the credential is available from this device) 15:23:23 JeanLuc: I think an ACS can guess and avoid a follow-up authentication 15:23:27 ack Ger 15:23:32 zakim, close the queue 15:23:32 ok, Ian, the speaker queue is closed 15:24:21 ACTION: Ian to work with pilot organizers to determine value of this change 15:25:27 Topic: EMVCo Input on SPC 15:25:50 [Doug Fisher slides] 15:26:11 SRCWG has content also... if no time today we can share another day 15:27:26 Doug: Slides include a visual to help with discussion; shows some enhancements (and corresponding SPC issues) 15:27:43 (Ian issues list : https://github.com/w3c/secure-payment-confirmation/issues ) 15:28:06 Doug: We've had some previous discussion (hence SPC issue numbers) 15:29:09 ...since previous discussions payeeName has been added to the specification 15:29:36 ...regarding small logo for instrument, the enlargement (e.g., on mouse over or select) could be interesting (as mentioned on GitHub) 15:30:10 ...so there are some (1) ux enhancements and (2) use cases we've discussed 15:30:15 q? 15:30:23 q+ 15:30:30 zakim, open the queue 15:30:30 ok, Ian, the speaker queue is open 15:30:32 I'll have one when we go into recurring + installments 15:31:04 Gerhard: We should discuss how "Total" relates to recurring data 15:31:11 dfisher: I have slides for details 15:31:32 Case 1: Fixed amount and fixed frequency (e.g., newspaper subscription) 15:31:50 dfisher: Don't focus on exact wording in the slides; intends to give a sense of things 15:32:36 ...in this case, the Total is the same as the fixed amount on the slide 15:33:02 q+ to ask who tracks this mandate? Is this just a consumer protection requirement or is this data submitted over the network with the authorization? 15:33:04 Case 2: Fixed amount and fixed frequency, but in the future (e.g., first month is free) 15:33:48 Case 3: Fixed amount and fixed frequency, above and beyond another part of a purchase (e.g., $100 purchase + agreement to subsequence recurrence of $5 monthly) 15:34:13 Case 4: Fixed amount and variable frequency (e.g., prepaid travel card) 15:34:25 Case 5: Variable amount, fixed frequency (e.g., utility bill) 15:34:49 Case 6: Variable amount, variable frequency (e.g., travel journey) 15:35:20 dfisher: Installments are similar: 15:35:20 q+ 15:35:22 Case 7: Installements (e.g., 3 months of payment of $30 for a total of $90) 15:35:45 dfisher: We have understood from previous conversations that the user agents are not fans of arbitrary text. 15:36:03 ...and thus if we could come up with a data dictionary that would help with support 15:36:14 ...the slides here show some initial ideas 15:37:09 ...e.g., an ACS could provide a merchant name, and some expectations about the meaning that would be represented (as strings) by the browser 15:37:12 q? 15:37:39 dfisher: The last slide shows the use case of non-payment transactions 15:37:46 ack AdrianHB_ 15:37:46 AdrianHB_, you wanted to ask who tracks this mandate? Is this just a consumer protection requirement or is this data submitted over the network with the authorization? 15:37:48 ack AdrianHB_ 15:38:11 AdrianHB_: This data that is captured; who is responsible for enforcing this? Or is it more about consumer protection? 15:38:37 ...is this for merchants in disputes? 15:38:44 ..or is it sent in initial authorization request 15:39:18 dfisher: This is viewed as being for consumer protection, and it's an area not well addressed today 15:39:30 ...it may be that this becomes an area with more focus moving forward 15:39:36 q+ 15:39:41 q+ to ask if the user would effectively sign over all of this data 15:39:57 dfisher: I think this is an opportunity for us, to address really for the first time properly, and I think it would really help SPC adoption 15:40:09 present+ Erhard_Brand 15:40:14 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 15:40:32 +1 - having a standard data dictionary for this would be a major advancement for any payment method. 15:40:48 q? 15:40:49 dfisher: I think we can get ahead of consumer consent movement with SPC 15:40:51 ack gkok 15:41:17 Gustavo: I think it's more complex than we perceive. Are you thinking EU in particular? 15:41:20 dfisher: yes. 15:41:42 Gustavo: We've seen this happen in other places (e.g., India) and there are so many different business models and use cases; clarity to the user is very challenging. 15:42:03 ...for example, in India we don't want users to have to re-authenticate if they upgrade. 15:42:14 ...e.g., with 3DS higher amount can be charged 15:42:29 ..but it's very hard to communicate to user "You will be charged 10 but could go up to 13" 15:42:50 ...bear in mind "frictionless" authentication; don't want to break our ability to do frictionless 15:43:17 ...so I am skeptical about ability to do this clearly 15:43:22 q+ to say that complexity should not prevent us from trying to solve the problem. The complexity is currently exploited to take advantage of users. We can sole simple use cases first 15:43:33 dfisher: Agreed it's complex. 15:43:54 ...we do want to make sure that consumers aren't taken through different authentication experiences depending on the type of transaction they happen to do 15:44:27 ...the more consistent application of SPC the better for users. 15:44:50 SameerT: Agree this is a complex topic; the proposal here is a minimum set of topics 15:45:22 Comment 15:45:23 ...the 3DS WG is also working on this in our own spec 15:45:26 q+ Gkok 15:45:42 ack SameerT 15:46:04 SameerT: Goal is uniformity in how user is challenged 15:46:15 ..for those merchants who want to use SPC for various use cases 15:46:21 ack AdrianHB_ 15:46:21 AdrianHB_, you wanted to say that complexity should not prevent us from trying to solve the problem. The complexity is currently exploited to take advantage of users. We can sole 15:46:24 ... simple use cases first 15:46:52 AdrianHB_: I think there's value in addressing 95% of use cases with a standardized model 15:47:15 ..if a payment plan is too complicated that may be by (nefarious) design 15:47:32 ..I think there would be value in standardized way of displaying standard models 15:47:55 ...it's challenging to turn the parameters into human-readable text 15:48:21 ...one way proceed is to start with human language descriptions that can be understood, then extract the data models from those statements 15:48:49 ...signing of the data would be a big value proposition 15:49:17 ...I think you can get to "future authorizations that are frictionless" based on something like this 15:49:40 ...so big +1 at least trying to solve this 15:49:45 ...and start with the simple cases 15:49:47 q? 15:49:52 ack Gkok 15:50:51 gkok: If you have something like this, it becomes hard to do 1-click payments. 15:51:07 ...would be concerned if there's a future where users always have to sign what they are doing.l 15:51:12 q+ 15:51:22 ack nicktr 15:51:22 nicktr, you wanted to ask if the user would effectively sign over all of this data 15:51:22 q+ to say this could ENABLE frictionless 15:52:04 NickTR: I hear the concern about friction, but I note that there is strong regulation about strong authentication (for some kinds of transaction) 15:52:12 ...Doug, were you expecting all this information to be signed? 15:52:31 ....or do you see this coming in PSD3? 15:52:57 dfisher: can't speak to PSD3, but regulators are looking at this topic. 15:53:03 q? 15:53:17 ack SameerT 15:53:48 SameerT: +1 to breaking down the sequence of frictionless....merchant could display whatever they want to the user before SPC is shown. 15:53:58 ...and then the "one click" is through SPC (with data displayed) 15:54:26 ...I don't think this will affect frictionless; issuer can always say frictionless ok before SPC is called 15:54:45 gkok: But then you don't have proof. And so there might be push to have the UX always shown. 15:54:57 q? 15:55:02 ack AdrianHB_ 15:55:02 AdrianHB_, you wanted to say this could ENABLE frictionless 15:55:53 AdrianHB_: Your comment just now helps me out ... I think it's unlikely we'd end up in a scenario where a regulator would mandate a particular technology. I think in general the regulator says what needs to be done, and the tech either helps address the requirement or it doesn.t 15:56:33 ...so the hope is that the merchant would be incentived, e.g., by something like a liability shift. The merchant never has to use this, but it helps the merchant in the future (e.g., always authorized, no liability) 15:56:52 ... merchant does not have to use this; can do something else. 15:56:54 ...imagine you are signing up for a subscription with value-added services 15:57:16 ..the mandate could say "We're going to charge you $5/month and we may charge up to $20/month for value-added services when you request them" 15:57:31 q? 15:57:43 ...that allows us to have the ability to charge for the value-added services without getting consent for additional payment 15:57:51 ..you've got pre-consent from the user 15:58:08 ...so I think there are several layers worth exploring; this is not all or nothing; I think we can address specific use cases 15:58:09 q? 15:58:14 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 15:59:01 dfisher: Just want to close with the non-payment use case (e.g., adding a card to a wallet) 15:59:40 Would this use SPC and not WebAuthn because it is still tied to a payment instrument? 15:59:56 (Ian thinks "SPC" Because it's more consent) 16:00:06 ADJOURNED until tomorrow 16:00:58 I have made the request to generate https://www.w3.org/2023/03/27-wpwg-minutes.html Ian 16:01:23 jpMarzetti has left #wpwg 17:00:35 rrsagent, bye 17:00:35 I see 3 open action items saved in https://www.w3.org/2023/03/27-wpwg-actions.rdf : 17:00:35 ACTION: Ian to work with Chairs to reach out to Apple to understand more from them [1] 17:00:35 recorded in https://www.w3.org/2023/03/27-wpwg-irc#T14-40-11 17:00:35 ACTION: Gustavo to help describe user journeys for continuing [2] 17:00:35 recorded in https://www.w3.org/2023/03/27-wpwg-irc#T15-21-13 17:00:35 ACTION: Ian to work with pilot organizers to determine value of this change [3] 17:00:35 recorded in https://www.w3.org/2023/03/27-wpwg-irc#T15-24-21 17:00:36 zakim, bye 17:00:36 leaving. As of this point the attendees have been Ian, Stephen_McGruer, Juan_Pablo_Marzetti, Holger_Kunkat, Giorgio_Mazzucchelli, Carey_Ferro, Anne_Pouillard, Jean_Luc_di_Manno, 17:00:36 Zakim has left #wpwg