Meeting minutes
SPC
Proposed: Low friction flows post v1
<Gerhard> +1 for that
<Ian> Jean-Luc: Regarding 3DS frictionless and 3DS
<smcgruer_[EST]> ... what does it meant to postpone?
<smcgruer_[EST]> Ian: We haven't talked about it enough to understand what it even means.
<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?
<smcgruer_[EST]> Ian: Is SPC not only in the challenge flow today?
<smcgruer_[EST]> ... I'm not aware of a frictionless flow integration.
<smcgruer_[EST]> Jean-Luc: That is why I raised this question. We should check with the EMVco folks.
<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?
<smcgruer_[EST]> Gerhard: I think that this is a terminology confusion.
<smcgruer_[EST]> ... in SPC-land, what we mean by 'frictionless' flow are ideas like getting a transaction UX window, but not require WebAuthn
<smcgruer_[EST]> ... that is not what 3DS means by frictionless
<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
<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
<smcgruer_[EST]> ... doesn't affect how the 3DS integration works at all, that should be fine.
<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
<smcgruer_[EST]> Ian: Moving on. Second group has to do with rebuilding the API
<smcgruer_[EST]> ... e.g., seems to be consensus that the API shouldn't actually use PaymentRequest long-term
<smcgruer_[EST]> ... but no current strong demand from pilot partners to change the API shape
<smcgruer_[EST]> ... known limitations, but propose we punt to post-V1
<Ian> Proposed: retool the API after v1 (issue 56, 65, 81)
<Ian> Gerhard: Would this create deprecation issues?
Stephen: We knew a while ago (October) that we would take on the compatibility issue. We are on board to postpone the API retooling.
… there are fewer payment partners than the general web, and they are very responsive, so we can wait until later in 2022 or 2023
Ian: Ok, sounds good. Next one is supporting multiple icons, e.g., for dark mode.
… would like to hear from PSPs how important it is
… current proposal is to stick with one icon for v1, and expand post-v1 if needed
Proposed: 1 icon for v1; expand as needed
Gerhard: My question - is this mandatory for 3DS?
ACTION: Jean-Luc to check on support for dark mode in 3DS
Jean-Luc: Not sure, will check.
Ian: Next. Four groups where I think we should continue to engage.
… reminder; getting to CR requires sign-off from four (?) cross-functional groups
… we have sign-off from TAG, still in discussions with privacy, i18n, accessibility
… likely need to schedule new chats with them to figure out next steps
… [Ian walks through the privacy issues briefly]
… We also have a set of issues to resolve with the WebAuthn folks.
… [Ian walks through WebAuthn issues]
… We have one prominent i18n issue
… We are waiting for the i18n folks to tell us the right way to proceed; common issue across many specs
… And have we an accessibility issue, which we think we can solve with a good practice spec note
… Basically recommend that the displayName string contains the same information as the card art icon
Ian: Can we close 168?
smcgruer_[EST]: Done
Ian: So top of the list are issues we should resolve in WPWG
Ian: First one; rich merchant details in transaction UX
… was a request for more branding from site, e.g. favicon
Input on issue 48?
Ian: 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
https://
Ian: Issue 97 is possibly minor, Stephen is following up
Ian: Issue 163, adding payeeName as alternative to payeeOrigin
https://
smcgruer_[EST]: this relates to the richer merchant detail information.
… we think that there will be a change to the spec to support payee name
… our thinking is to support both name / origin.
… we'll show either one, or both
Bart: Deja vu wrt PR API
Bart: +1 to name
Susan: Has this been tested in the pilot
smcgruer_[EST]: Yes, this change came from a pilot
… but not aware of user studies yet
Susan: I imagine merchant wants name to be seen
Gerhard: Want to check - any verification of the payeeOrigin?
smcgruer_[EST]: There is no verification of origin
… Adyen use case involves a redirect
… you are on adyen.com but they want to display airbnb.com
… the assertion does contain information about where the user actually is
Ian: I recall four origins in the assertion:
- Top level
- PSP / caller
- data provided as input
- RP origin
smcgruer_[EST]: Three of those are browser-determined.
… the fourth is up to the verifier to determine whether it's the origin they expect
Gerhard: Yeah, so we've found that a bit complicated on our side, to define clearly for an integrity perspective
Gerhard: It may create complications
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
Gerhard: Definitely in the card payment world, the merchant name matters. If we can say that this conforms to that, it may be useful.
… If it doesn't match that, it may help or hurt customer
… Could lie about your name to mislead the client about reputation
smcgruer_[EST]: the part I'm not sure about - how to enforce the merchant is "using their real name".
… I think that can be handled by the verifier; the browser can't do that.
Gerhard: I'm not expecting the browser to do that.
… just thinking about wording in spec
… and whether payeeName needs to be part of payment authorization request
<Zakim> ChrisD, you wanted to ask how issues 48 and 163 relate - they seem close in motivation
Chris: 48 and 163 seem closely related, e.g. Gerhard's questions for 163 relate to 48 as well
… lot of complexity here around what information is guaranteed by browser versus claim by merchant, etc
… also handling the PSP redirect use-case too
Ian: I agree, 48 and 163 are related. 48 is maybe visionary, 163 is a specific case
Ian: Model has been - security is handled by the validator.
… Is that model good enough, is the question.
ChrisD: Validator is usually the relying party/bank
… 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
Gerhard: There is in 3DS, not sure about Open Banking
… in ISO world though, no payeeOrigin or payeeLogo
… so shouldn't we just do payeeName ?
PROPOSED: PayeeName mandatory, payee origin optional
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
smcgruer_[EST]: For backwards compatibility making something new mandatory is a breaking change.
… what's nice about 'just adding the name' is that the validator can have its own policy on what should be provided.
… I understand the note, but we would prefer doing this in a backwards compatible way
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
… in the point of sale world, there's zero merchant info, you just trust that it ends up with the merchant!
Ian: Similar add-on - the site itself could display whatever it wants
<Zakim> Ian, you wanted to mention misleading display
Ian: so the site could already be presenting itself fradulently, not clear why this UX has to be better
… what's nice is that its signed and so the validator KNOWS what the site has claimed. Arguably even better?
Gerhard: I agree, we should look at the value, and also see if we can make it better too.
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 ?
Gerhard: Happy to comment, but I think we really want the merchant side to comment.
Ian: Moving on; last two issues are 109 (GDPR requirements) and 172 (opt-out link)
… seem related; the latter is a proposal to deal with the former
… this is about how to easily get back to the RP to ask them to forget your registration
… since SPC is coupled, no immediate 1p relationship
Ian: Got updates on 172?
smcgruer_[EST]: We are still discussing.
… we have some concerns about putting non-verified information in trustworthy browser UX.
… we've just discussed this a bit re: icon/name (and how that is handled)
… but adding a link to an arbitrary site from trusted UX is more concerning.
Ian: Would love to hear on others weighing in on the importance of this issue to them
Gerhard: Haven't read issue, but basically need to help the user to opt-out, right?
smcgruer_[EST]: Proposal was to include a link to the RP site
… issuer or other
… because it's hard to opt-out to manually go to a site to opt-out
Gerhard: Is this more a webauthn thing? Maybe FIDO should have an opt-out mechanism built into token creation?
Ian: Are there discussions in the WebAuthn WG about GDPR/opt-out support?
John Fontana: Not familiar to me, but will follow up.
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"
… I am not a lawyer to know whether that suffices from GDPR perspective
… 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
… harder for the browser here because the browser cannot authenticate the user in this case
… another question is whether "signal from the browser" is good enough for GDPR purposes.
… 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
Gerhard: Last thing I want to do is authenticate to opt-out; the user should just be able to say "no"
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.
Ian: Ok, our time is up! Thanks everyone for the discussion.
… I'm going to take an AI to mark issues as post-V1, will start working on cross-group meetings
… and welcome feedback on the small number of issues which need WPWG input
Next meeting
17 March
Ian: Next call is 17 march