14:53:40 <RRSAgent> RRSAgent has joined #wpwg
14:53:40 <RRSAgent> logging to https://www.w3.org/2022/03/03-wpwg-irc
14:53:41 <Ian> agenda?
14:53:45 <Ian> zakim, clear agenda
14:53:45 <Zakim> agenda cleared
14:53:54 <Ian> RRSAGent, pointer?
14:53:54 <RRSAgent> See https://www.w3.org/2022/03/03-wpwg-irc#T14-53-54
14:54:06 <Ian> zakim, bye
14:54:06 <Zakim> leaving.  As of this point the attendees have been Ian_Jacobs, Herve_Robache, Detlef_Hillen, Ortwin_Scheja, Kris_Ketels, Stephen_McGruer, Sameer_Tare, Wijnand_Machielse,
14:54:06 <Zakim> Zakim has left #wpwg
14:54:09 <Zakim> Zakim has joined #wpwg
14:54:10 <Zakim> ... Chris_Wood, Manish_Garg, Vincent_Kuntz, Ryan_Watkins, Susan_Pandy, Leigh_Garner, Gerhard_Oosthuizen, Tomoya_Horiguchi
14:54:15 <Ian> Meeting: Web Payments Working Group
14:54:28 <Ian> Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20220303
14:54:32 <Ian> Scribe: Ian
14:54:48 <Ian> agenda+ SPC
14:55:00 <Ian> present+ Ian_Jacobs
14:58:05 <Ian> present+ John_Fontana
15:01:00 <Anne> Anne has joined #wpwg
15:01:37 <Ian> present+ Stephen_McGruer
15:01:37 <Ian> present+ Stephen_McGruer
15:01:44 <Ian> present+ Anne_Pouillard
15:01:51 <Ian> present+ Carey_Ferro
15:01:57 <Ian> present+ Nick_Burris
15:02:04 <Ian> present+ Jonathan_Grossar
15:02:10 <Ian> present+ David_Benoit
15:02:15 <Ian> present+ Ryan_Watkins
15:02:29 <Ian> present+ Suzie_Annezo-Sebire
15:02:37 <Ian> present+ Jean-Luc_di_Manno
15:02:39 <Ian> present+ Chris_Dee
15:02:46 <jeanLuc> jeanLuc has joined #WPWG
15:02:49 <Ian> present+ Tomoya_Horiguchi
15:02:56 <Ian> present+ Jean-Michel_Girard
15:03:03 <Ian> present+ Susan_Pandy
15:03:09 <ChrisD> ChrisD has joined #wpwg
15:03:11 <jonathan> jonathan has joined #wpwg
15:03:26 <Ian> present+ Bart_de_Water
15:03:49 <Ian> zakim, take up item 1
15:03:49 <Zakim> agendum 1 -- SPC -- taken up [from Ian]
15:03:55 <Ian> Chair: Ian
15:04:40 <Ian> -> https://www.w3.org/2022/03/01-spc-triage.txt triage list
15:04:44 <Ian> present+ Gerhard
15:06:27 <smcgruer_[EST]> q?
15:06:42 <Gerhard> Gerhard has joined #wpwg
15:07:25 <JMGirard_> JMGirard_ has joined #wpwg
15:08:01 <Gerhard> +1 for that
15:08:16 <Ian> (Low friction flows post v1)
15:08:26 <smcgruer_[EST]> scribe: smcgruer
15:08:55 <Ian> Jean-Luc: Regarding 3DS frictionless and 3DS
15:09:21 <smcgruer_[EST]> ... what does it meant to postpone?
15:09:32 <smcgruer_[EST]> Ian: We haven't talked about it enough to understand what it even means.
15:10:02 <smcgruer_[EST]> Jean-Luc: Note that v2.3 has been released and will soon go through testing/verification. So we need to consider SPC in 3DS currently?
15:10:13 <smcgruer_[EST]> Ian: Is SPC not only in the challenge flow today?
15:10:35 <clinton> clinton has joined #wpwg
15:10:38 <smcgruer_[EST]> ... I'm not aware of a frictionless flow integration.
15:11:09 <smcgruer_[EST]> Jean-Luc: That is why I raised this question. We should check with the EMVco folks.
15:11:24 <Gerhard> q+
15:11:39 <smcgruer_[EST]> ack Gerhard
15:11:44 <smcgruer_[EST]> Ian: To be clear, we're not stopping progress of SPC in any way. The question is does SPC need extra features for use in a frictionless flow?
15:11:54 <smcgruer_[EST]> Gerhard: I think that this is a terminology confusion.
15:12:23 <smcgruer_[EST]> ... in SPC-land, what we mean by 'frictionless' flow are ideas like getting a transaction UX window, but not require WebAuthn
15:12:30 <smcgruer_[EST]> ... that is not what 3DS means by frictionless
15:12:58 <smcgruer_[EST]> ... the idea was to meet use-cases outside of Europe where you don't need full 3DS, but you might still want some consent from the user
15:12:59 <Ian> present+ Clinton_Allen
15:13:16 <smcgruer_[EST]> ... the reason to punt is that so far we've seen most traction with SPC + WebAuthn, so let's keep going with that
15:13:25 <smcgruer_[EST]> ... doesn't affect how the 3DS integration works at all, that should be fine.
15:14:04 <smcgruer_[EST]> Jean-Luc: Clearer, thanks. Additional question - current 3DS v2.3 has an additional AReq/ARes, and [editor: missed this] this is frictionless to us
15:14:12 <smcgruer_[EST]> q?
15:14:41 <smcgruer_[EST]> Ian: Moving on. Second group has to do with rebuilding the API
15:15:03 <smcgruer_[EST]> ... e.g., seems to be consensus that the API shouldn't actually use PaymentRequest long-term
15:15:11 <smcgruer_[EST]> ... but no current strong demand from pilot partners to change the API shape
15:15:21 <smcgruer_[EST]> ... known limitations, but propose we punt to post-V1
15:15:30 <Ian> Proposed: retool the API after v1 (issue 56, 65, 81)
15:15:37 <Gerhard> q+
15:15:43 <smcgruer_[EST]> ack Gerhard
15:15:44 <Ian> ack g
15:16:00 <Ian> Gerhard: Would this create deprecation issues?
15:16:05 <Ian> scribe+ Ian
15:16:37 <Carey_Ferro> Carey_Ferro has joined #wpwg
15:16:43 <Ian> Stephen: We knew a while ago (October) that we would take on the compatibility issue. We are on board to postpone the API retooling.
15:17:07 <Ian> ...there are fewer payment partners than the general web, and they are very responsive, so we can wait until later in 2022 or 2023
15:17:10 <Ian> q?
15:17:12 <smcgruer_[EST]> scribe+ smcgruer_[EST]
15:17:50 <smcgruer_[EST]> Ian: Ok, sounds good. Next one is supporting multiple icons, e.g., for dark mode.
15:18:05 <smcgruer_[EST]> ... would like to hear from PSPs how important it is
15:18:16 <smcgruer_[EST]> ... current proposal is to stick with one icon for v1, and expand post-v1 if needed
15:18:22 <Ian> Proposed: 1 icon for v1; expand as needed
15:19:05 <smcgruer_[EST]> Gerhard: My question - is this mandatory for 3DS?
15:19:06 <Ian> ACTION: Jean-Luc to check on support for dark mode in 3DS
15:19:10 <smcgruer_[EST]> Jean-Luc: Not sure, will check.
15:19:28 <smcgruer_[EST]> q?
15:19:57 <smcgruer_[EST]> Ian: Next. Four groups where I think we should continue to engage.
15:20:10 <smcgruer_[EST]> ... reminder; getting to CR requires sign-off from four (?) cross-functional groups
15:20:22 <smcgruer_[EST]> ... we have sign-off from TAG, still in discussions with privacy, i18n, accessibility
15:20:33 <smcgruer_[EST]> ... likely need to schedule new chats with them to figure out next steps
15:21:13 <smcgruer_[EST]> ... [Ian walks through the privacy issues briefly]
15:23:34 <smcgruer_[EST]> ... We also have a set of issues to resolve with the WebAuthn folks.
15:24:05 <smcgruer_[EST]> ... [Ian walks through WebAuthn issues]
15:24:26 <smcgruer_[EST]> ... We have one prominent i18n issue
15:24:40 <smcgruer_[EST]> ... We are waiting for the i18n folks to tell us the right way to proceed; common issue across many specs
15:25:03 <smcgruer_[EST]> ... And have we an accessibility issue, which we think we can solve with a good practice spec note
15:25:23 <smcgruer_[EST]> ... Basically recommend that the displayName string contains the same information as the card art icon
15:26:34 <Ian> Ian: Can we close 168?
15:26:40 <Ian> smcgruer_[EST]: Done
15:26:52 <smcgruer_[EST]> Ian: So top of the list are issues we should resolve in WPWG
15:27:03 <smcgruer_[EST]> Ian: First one; rich merchant details in transaction UX
15:27:12 <smcgruer_[EST]> ... was a request for more branding from site, e.g. favicon
15:27:38 <Ian> Input on issue 48?
15:27:38 <smcgruer_[EST]> ... I think we have some good folks in the room from PSPs who might be able to speak to whether there needs to be more info here
15:27:46 <Ian>    https://github.com/w3c/secure-payment-confirmation/issues/48
15:27:47 <smcgruer_[EST]> q?
15:28:37 <smcgruer_[EST]> Ian: Issue 97 is possibly minor, Stephen is following up
15:28:52 <smcgruer_[EST]> Ian: Issue 163, adding payeeName as alternative to payeeOrigin
15:28:58 <Ian>    https://github.com/w3c/secure-payment-confirmation/issues/163
15:29:07 <Ian> smcgruer_[EST]: this relates to the richer merchant detail information.
15:29:27 <Ian> ...we think that there will be a change to the spec to support payee name
15:29:55 <Ian> ...our thinking is to support both name / origin.
15:30:01 <Ian> ...we'll show either one, or both
15:30:10 <Ian> Bart: Deja vu wrt PR API
15:30:22 <Gerhard> q+
15:30:40 <Ian> Bart: +1 to name
15:30:44 <smcgruer_[EST]> Susan: Has this been tested in the pilot
15:31:00 <Ian> smcgruer_[EST]: Yes, this change came from a pilot
15:31:06 <ChrisD> q+ to ask how issues 48 and 163 relate - they seem close in motivation
15:31:11 <Ian> ...but not aware of user studies yet
15:31:18 <smcgruer_[EST]> q?
15:31:21 <smcgruer_[EST]> ack Gerhard
15:31:27 <Ian> Susan: I imagine merchant wants name to be seen
15:31:31 <smcgruer_[EST]> Gerhard: Want to check - any verification of the payeeOrigin?
15:31:54 <Ian> smcgruer_[EST]: There is no verification of origin
15:32:02 <Ian> ...Adyen use case involves a redirect
15:32:14 <Ian> ...you are on adyen.com but they want to display airbnb.com
15:32:35 <Ian> ...the assertion does contain information about where the user actually is
15:33:17 <Ian> Ian: I recall four origins in the assertion:
15:33:18 <Ian>  - Top level
15:33:21 <Ian> - PSP / caller
15:33:25 <Ian> - data provided as input
15:33:27 <Ian> - RP origin
15:33:37 <Ian> smcgruer_[EST]: Three of those are browser-determined.
15:33:48 <Ian> ..the fourth is up to the verifier to determine whether it's the origin they expect
15:34:08 <smcgruer_[EST]> Gerhard: Yeah, so we've found that a bit complicated on our side, to define clearly for an integrity perspective
15:34:10 <Ian> Gerhard: It may create complications
15:35:14 <smcgruer_[EST]> Ian: So for example, if you're on etsy, you might want to provide a different shop name and/or origin, but the assertion will also contain top-level == etsy.com
15:35:40 <smcgruer_[EST]> Gerhard: Definitely in the card payment world, the merchant name matters. If we can say that this conforms to that, it may be useful.
15:35:54 <smcgruer_[EST]> ... If it doesn't match that, it may help or hurt customer
15:36:08 <smcgruer_[EST]> ... Could lie about your name to mislead the client about reputation
15:36:11 <smcgruer_[EST]> q?
15:36:42 <Ian> smcgruer_[EST]: the part I'm not sure about - how to enforce the merchant is "using their real name".
15:36:51 <Ian> ...I think that can be handled by the verifier; the browser can't do that.
15:37:01 <Ian> Gerhard: I'm not expecting the browser to do that.
15:37:07 <Ian> ...just thinking about wording in spec
15:37:37 <Ian> ...and whether payeeName needs to be part of payment authorization request
15:38:26 <Ian> ack Chris
15:38:26 <Zakim> ChrisD, you wanted to ask how issues 48 and 163 relate - they seem close in motivation
15:39:13 <smcgruer_[EST]> Chris: 48 and 163 seem closely related, e.g. Gerhard's questions for 163 relate to 48 as well
15:40:07 <smcgruer_[EST]> ... lot of complexity here around what information is guaranteed by browser versus claim by merchant, etc
15:40:13 <smcgruer_[EST]> ... also handling the PSP redirect use-case too
15:40:23 <smcgruer_[EST]> Ian: I agree, 48 and 163 are related. 48 is maybe visionary, 163 is a specific case
15:40:28 <smcgruer_[EST]> q+
15:40:48 <smcgruer_[EST]> Ian: Model has been - security is handled by the validator.
15:40:58 <smcgruer_[EST]> ... Is that model good enough, is the question.
15:41:06 <smcgruer_[EST]> ChrisD: Validator is usually the relying party/bank ?
15:41:10 <smcgruer_[EST]> s/?//
15:41:32 <smcgruer_[EST]> ... question is will they have a good ability to validate that certain passed in information was wrong, e.g. do they have the right information somehwere
15:41:40 <smcgruer_[EST]> Gerhard: There is in 3DS, not sure about Open Banking
15:41:58 <smcgruer_[EST]> ... in ISO world though, no payeeOrigin or payeeLogo
15:42:05 <smcgruer_[EST]> ... so shouldn't we just do payeeName ?
15:42:21 <Ian> PROPOSED: PayeeName mandatory, payee origin optional
15:42:54 <smcgruer_[EST]> ChrisD: I get it from the merchant point of view, wanting their branding more present, but from the validator point of view I see the concerns about being misleading
15:42:55 <smcgruer_[EST]> q+
15:43:07 <Ian> q+ to mention misleading display
15:43:13 <Ian> ack sm
15:43:34 <Ian> smcgruer_[EST]: For backwards compatibility making something new mandatory is a breaking change.
15:43:58 <Ian> ..what's nice about 'just adding the name' is that the validator can have its own policy on what should be provided.
15:44:23 <Ian> ..I understand the note, but we would prefer doing this in a backwards compatible way
15:45:00 <smcgruer_[EST]> Bart: Thinking outloud, I think Google Pay has a payeeName concept that is not validated at all, and afaik is not a vector for fraud
15:45:21 <smcgruer_[EST]> ... in the point of sale world, there's zero merchant info, you just trust that it ends up with the merchant!
15:45:33 <smcgruer_[EST]> Ian: Similar add-on - the site itself could display whatever it wants
15:45:50 <Ian> ack me
15:45:50 <Zakim> Ian, you wanted to mention misleading display
15:45:51 <smcgruer_[EST]> ... so the site could already be presenting itself fradulently, not clear why this UX has to be better
15:46:07 <smcgruer_[EST]> ... what's nice is that its signed and so the validator KNOWS what the site has claimed. Arguably even better?
15:46:38 <smcgruer_[EST]> Gerhard: I agree, we should look at the value, and also see if we can make it better too.
15:47:29 <smcgruer_[EST]> Ian: Can I give you an AI to state the case for adding guidance to spec and/or change proposal in 163 wrt optional/required ?
15:47:41 <smcgruer_[EST]> Gerhard: Happy to comment, but I think we really want the merchant side to comment.
15:48:31 <smcgruer_[EST]> Ian: Moving on; last two issues are 109 (GDPR requirements) and 172 (opt-out link)
15:48:37 <smcgruer_[EST]> ... seem related; the latter is a proposal to deal with the former
15:49:07 <smcgruer_[EST]> ... this is about how to easily get back to the RP to ask them to forget your registration
15:49:14 <smcgruer_[EST]> ... since SPC is coupled, no immediate 1p relationship
15:49:45 <Ian> Ian: Got updates on 172?
15:49:50 <Ian> smcgruer_[EST]: We are still discussing.
15:50:15 <Ian> ...we have some concerns about putting non-verified information in trustworthy browser UX.
15:50:30 <Ian> ...we've just discussed this a bit re: icon/name (and how that is handled)
15:50:43 <Ian> ..but adding a link to an arbitrary site from trusted UX is more concerning.
15:51:07 <smcgruer_[EST]> Ian: Would love to hear on others weighing in on the importance of this issue to them
15:51:29 <smcgruer_[EST]> Gerhard: Haven't read issue, but basically need to help the user to opt-out, right?
15:52:51 <Ian> smcgruer_[EST]: Proposal was to include a link to the RP site
15:52:59 <Ian> ...issuer or other
15:53:12 <Ian> ..because it's hard to opt-out to manually go to a site to opt-out
15:53:28 <smcgruer_[EST]> Gerhard: Is this more a webauthn thing? Maybe FIDO should have an opt-out mechanism built into token creation?
15:54:29 <smcgruer_[EST]> Ian: Are there discussions in the WebAuthn WG about GDPR/opt-out support?
15:54:40 <smcgruer_[EST]> John Fontana: Not familiar to me, but will follow up.
15:56:05 <Ian> smcgruer_[EST]: We have also been wondering about a flow where user clicks on "opt-out"; does an authentication ceremony in the browser; and then the browser sends the assertion to the RP with "type opt-out"
15:56:18 <Ian> ...I am not a lawyer to know whether that suffices from GDPR perspective
15:56:44 <Ian> ...second topic is that if you don't have a credential for THIS DEVICE, do you still have to offer an opt-out option for this device
15:56:54 <Ian> ...harder for the browser here because the browser cannot authenticate the user in this case
15:57:15 <Ian> ...another question is whether "signal from the browser" is good enough for GDPR purposes.
15:57:52 <Ian> ...regarding Gerhard's proposal to add opt-out link to WebAuthn, that might be better but we'd still possibly be concerned because the registration-time URL is to a bad origin
15:58:23 <Ian> Gerhard: Last thing I want to do is authenticate to opt-out; the user should just be able to say "no"
15:59:00 <smcgruer_[EST]> Ian: Again, Gerhard, if you could offer that view on the issue that would be great. There is some concern with the no-authentication flow is that someone could maliciously trigger opt-outs.
15:59:15 <smcgruer_[EST]> Ian: Ok, our time is up! Thanks everyone for the discussion.
15:59:31 <smcgruer_[EST]> ... I'm going to take an AI to mark issues as post-V1, will start working on cross-group meetings
15:59:40 <smcgruer_[EST]> ... and welcome feedback on the small number of issues which need WPWG input
15:59:49 <Ian> Topic: Next meeting
15:59:51 <Ian> 17 March
15:59:52 <smcgruer_[EST]> Ian: Next call is 17 march
15:59:56 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/03-wpwg-minutes.html Ian
16:06:54 <Ian> RRSAGENT, set logs public