Meeting minutes
See also: 28 March minutes, 29 March minutes
Welcome
NickTR: Welcome all. Please review antitrust guidance and Code of Ethics and Professional Conduct.
[Nick does overview of the Agenda https://
Where we Are
[Ian will not minute most of what Nick covers in slides]
[But will type highlights]
NickTR: Congrats on PR API to Recommendation (Q4 2022)
NickTR: Thanks also to Gerhard and Praveena who joined me as co-Chairs as of the last rechartering!
NickTR: W3C now an incorporated non-profit (no longer MIT project)
<Gerhard> 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?
NickTR: I think SPC is genuinely solving a problem that has not been previously solved.
NickTR: Horizontal review is nearly completed; awaiting privacy review
… once we have addresses any issues, we can advance to Candidate Recommendation
NickTR: Will look forward to more pilot results at TPAC (in September, in Seville)
NickTR: PIX growth is phenomenal; will be very interesting to hear more about that
Charter issue
PROPOSED: Restore text in charter
<Gerhard> +1 to restore
AdrianHB_: Can we wait to hear more from Tess (who raised the issue) before we make a resolution in the WG? I'd like to understand the motivation for the request before we resolve this
Clinton: The language is "user agent specifics"; leaves open room for interpretation
smcgruer_[EST]: Payment journeys are very user-focused, including visual elements (plus accessibility); I understand why complicated
nicktr: What level of charter review would be necessary here?
Ian: Full review, meaning: decision by the WG, approval by management, review by the AC. Although we would communicate in review by the AC that we are just adding a couple of sentences, there could be objections to other parts of the charter.
Gerhard: It sounds like a lot of work.The way I read the text (being proposed to add back): it allows us to do SPC provided we stay general about display of fields
… also good to leave room for competition among browsers
… I don't think our spec is overly prescriptive
… since it was in the charter previously, seems ok to add back
<Zakim> AdrianHB_, you wanted to say that we risk preventing ourselves from writing a spec that can be adopted under certain legal regimes
<nicktr> ack
AdrianHB_: (1) It is a lot of work and there's a risk of derailing the charter. I am concerned language restricting discussion of UI may prevent us from doing some work
NickTR: The proposal is not carried.
… we'll wait for Apple to provide more information
ACTION: Ian to work with Chairs to reach out to Apple to understand more from them
SPC UX
<nicktr> [Ian presents slides]
<nicktr> ian: responding to feedback from Tomasz, Stephen and I have worked on a potential improvement to the flow of SPC
<nicktr> [background considerations]
<nicktr> ian: WebAuthn privacy requirements
<nicktr> ...Don't want link to arbitrary page from secure UX
<nicktr> [Current Situation]
<nicktr> [New behaviour]
<nicktr> ian: User gets full transaction information whether there are matching credentials or not
<nicktr> ...we propose introducing a new signal (authenticate another way and no matching credentials both send same signal)
<nicktr> Gerhard: I like this approach
<nicktr> ian: perceived benefits: no leakage about no matching credentials, new signal continue v cancel, easier to understand the UX
<nicktr> Gerhard: If credential id is not present, will the user know?
<nicktr> Stephen: the user does not know. What should be communicated to user is an open questions
<nicktr> ...it could be based around "passkey"
<nicktr> Gerhard: I like this because the signal is now clearer between "cancel" and "continue". As a user of the API, 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
<nicktr> ...so this proposal is an improvement
<nicktr> ...but it's my understanding that the user has to be in the same browser instance
<nicktr> Stephen: that's true. On Android, there is full integration to include passkey
<nicktr> ...on Windows, there's a potential path to implementation of something similar
<nicktr> ...it's not clear what the pathway is in the Apple ecosystem
<nicktr> Gerhard: We really need the passkey piece - without that, the UX would be strongly suboptimal
Gerhard: +1 to this enhancement
… would be nice to be explicit to user about "no passkeys available"
<nicktr> ...I would like to give users a hint about passkey if we can
Gerhard: Could you dispense with the "Confirm" button on the fallback?
<Zakim> 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)
<nicktr> AdrianHB_: this is an improvement
AdrianHB: Risk that user does not understand that "confirm" will involve MORE AUTH rather than "just payment"
<nicktr> ...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
<nicktr> ...so I'd like to see user experience research
AdrianHB_: Should be clearer "Please confirm details; we will authenticate you after you do"
<nicktr> ...the message should be explicit about the authentication not being built in in the "confirm" flow
<nicktr> smcgruer_[EST]: I agree
<nicktr> ...one idea might be to give the caller to specify their fallback authentication
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"
<nicktr> Gerhard: what if we say "would you still like to authenticate"?
Gerhard; What if "Authenticate a different way" is the same link in the fallback, and only a "Cancel" button ?
… so consistency with location and meaning of that "other way" link
<AdrianHB_> +1 Ian/Stephen - a hint as to the way auth will be done after this confirm screen sounds like an idea worth exploring
smcgruer_[EST]: We should not go too deep into the specifics of the UX :)
<nicktr> smcgruer_[EST]: this takes us exactly into the space we were discussing in the context of the charter text
<nicktr> ian: nobody is saying here "this is exactly what the browser must render"
<nicktr> Gerhard: we should limit ourselves to events
<nicktr> gustavo: Typically, issuer (not merchant) determines next authentication method. As a merchant, I don't control what happens next - the ASPSP defines the fallback
<nicktr> ...perhaps we should have an enumeration of the possible fallbacks?
Gustavo: not sure about "Confirm" button
<cferro> perhaps it's better to use "continue" versus "confirm"
<praveenas_> +1 on Gustavo's comment
<nicktr> clinton: can we make requirements of the UX without saying what the UX should be
<nicktr> smcgruer_[EST]: the spec can't require how it looks - it can talk about flows
NickTR: Difference here between W3C specs and EMVCo specs (which have more specific UX requirements)
<nicktr> Gerhard: is it allowed to say "these fields must/should be displayed"?
<smcgruer_[EST]> https://
<smcgruer_[EST]> "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" ...
<smcgruer_[EST]> "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:"
<smcgruer_[EST]> "The payeeName if it is present., The ..."
<Gerhard> Thanks smgruer!
dfisher: I think the "Confirm" could serve a useful purpose and might even lead to a frictionless UX
… that the user confirmed the details of the purchase.
Ian: Interesting! If the bank is the caller of SPC, then even with a simple "continue" button (without a FIDO assertion) they can have some increased confidence that the browser presented information to the user and the user agreed. [Ed Note: After the call it became clearer that this would not likely happen because the ACS would have chosen to challenge based on risk assessment and would not simply accept "continue" as sufficient.] When the merchant calls SPC, on the other hand, there is no way for the bank to validate (in the 3DS case) that what they asked the merchant to provide as input was in fact provided as input to the API.
<AdrianHB_> +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?
Gustavo: I would also be intrigued if issuers were more comfortable with frictionless if they knew what the user saw.
… if you had something like the no matching credentials windows and were more explicit about no matching passkeys in that window,
… 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
… and so this UX needs to be really clear for the majority of users
<Gerhard> question: Always willing to discuss 'frictionless' flows and scenario's on Wednesday too?
smcgruer_[EST]: If we did the fallback UX shown in the slides, would that change adoption status and, is it sufficient?
… I'd love to have a partner to origin trial this
<AdrianHB_> Is it possible that the "Confirm" screen could post a 1st-party request to the RP in the background to facilitate frictionless?
Gerhard: I think it would be a terrible experience if the user wants to cancel and then we proceed to try to authenticate them. so I think this is a significant improvement.
smcgruer_[EST]: I don't disagree with you; the scenario we envisage today is that the user has pushed "pay" to begin with
Gerhard: There are cases where the user "wants to go back" and so "cancel" is an important option
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.
Gustavo: I am interested in the idea where the user has a better sense of what happens next.
… I'd be happy to help sketch out the scenarios
… it should be possible to say "cancel" (and that happens in 3DS frames)
… for the nuanced topics (confirm/continue), it would be valuable to sketch out the exact user journeys to inform those discussions
<praveenas_> +1 on Gustavo's comments, also happy to help there.
ACTION: Gustavo to help describe user journeys for continuing
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.
(Ian: but they don't know the credential is available from this device)
JeanLuc: I think an ACS can guess and avoid a follow-up authentication
ACTION: Ian to work with pilot organizers to determine value of this change
EMVCo Input on SPC
[Doug Fisher presents slides from EMVCo 3DS Working Group]
<clinton> SRCWG has content also... if no time today we can share another day
Doug: Slides include a visual to help with discussion; shows some enhancements (and corresponding SPC issues)
Doug: We've had some previous discussion (hence SPC issue numbers)
… since previous discussions payeeName has been added to the specification
… regarding small logo for instrument, the enlargement (e.g., on mouse over or select) could be interesting (as mentioned on GitHub)
… so there are some (1) ux enhancements and (2) use cases we've discussed
<gkok> I'll have one when we go into recurring + installments
Gerhard: We should discuss how "Total" relates to recurring data
dfisher: I have slides for details. Don't focus on exact wording in the slides; intends to give a sense of things
… in this case, the Total is the same as the fixed amount on the slide
Case 1: Fixed amount and fixed frequency (e.g., newspaper subscription)
Case 2: Fixed amount and fixed frequency, but in the future (e.g., first month is free)
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)
Case 4: Fixed amount and variable frequency (e.g., prepaid travel card)
Case 5: Variable amount, fixed frequency (e.g., utility bill)
Case 6: Variable amount, variable frequency (e.g., travel journey)
Case 7: Installments (e.g., 3 months of payment of $30 for a total of $90)
dfisher: We have understood from previous conversations that the user agents are not fans of being asked to display arbitrary text in secure modal windows.
… and thus if we could come up with a data dictionary that would help with support
… the slides here show some initial ideas
… e.g., an ACS could provide a merchant name, and some expectations about the meaning that would be represented (as strings) by the browser
dfisher: The last slide shows the use case of non-payment transactions
<Zakim> 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?
AdrianHB_: This data that is captured; who is responsible for enforcing this? Or is it more about consumer protection?
… is this for merchants in disputes?
… or is it sent in initial authorization request
dfisher: This is viewed as being for consumer protection, and it's an area not well addressed today
… it may be that this becomes an area with more focus moving forward
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
<AdrianHB_> +1. Having a standard data dictionary for this would be a major advancement for any payment method.
dfisher: I think we can get ahead of consumer consent movement with SPC
Gustavo: I think it's more complex than we perceive. Are you thinking EU in particular?
dfisher: yes.
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.
… for example, in India we don't want users to have to re-authenticate if they upgrade.
… e.g., with 3DS higher amount can be charged
… but it's very hard to communicate to user "You will be charged 10 but could go up to 13"
… bear in mind "frictionless" authentication; don't want to break our ability to do frictionless
… so I am skeptical about ability to do this clearly
dfisher: Agreed it's complex.
… 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
… the more consistent application of SPC the better for users.
SameerT: Agree this is a complex topic; the proposal here is a minimum set of topics. The 3DS WG is also working on this in our own spec. Goal is uniformity in how user is challenged
… for those merchants who want to use SPC for various use cases
<Zakim> 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 simple use cases first
AdrianHB_: I think there's value in addressing 95% of use cases with a standardized model
… if a payment plan is too complicated that may be by (nefarious) design
… I think there would be value in standardized way of displaying standard models
… it's challenging to turn the parameters into human-readable text
… one way proceed is to start with human language descriptions that can be understood, then extract the data models from those statements
… signing of the data would be a big value proposition
… I think you can get to "future authorizations that are frictionless" based on something like this
… so big +1 at least trying to solve this
… and start with the simple cases
gkok: If you have something like this, it becomes hard to do 1-click payments.
… would be concerned if there's a future where users always have to sign what they are doing.l
<Zakim> nicktr, you wanted to ask if the user would effectively sign over all of this data
NickTR: I hear the concern about friction, but I note that there is strong regulation about strong authentication (for some kinds of transaction)
… Doug, were you expecting all this information to be signed?
… or do you see this coming in PSD3?
dfisher: can't speak to PSD3, but regulators are looking at this topic.
SameerT: +1 to breaking down the sequence of frictionless....merchant could display whatever they want to the user before SPC is shown.
… and then the "one click" is through SPC (with data displayed)
… I don't think this will affect frictionless; issuer can always say frictionless ok before SPC is called
gkok: But then you don't have proof. And so there might be push to have the UX always shown.
<Zakim> AdrianHB_, you wanted to say this could ENABLE frictionless
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
… 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)
… merchant does not have to use this; can do something else.
… imagine you are signing up for a subscription with value-added services
… 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"
… that allows us to have the ability to charge for the value-added services without getting consent for additional payment
… you've got pre-consent from the user
… so I think there are several layers worth exploring; this is not all or nothing; I think we can address specific use cases
dfisher: Just want to close with the non-payment use case (e.g., adding a card to a wallet)
<AdrianHB_> Would this use SPC and not WebAuthn because it is still tied to a payment instrument?
(Ian thinks "SPC" Because it's more consent)
ADJOURNED until tomorrow
See also: 28 March minutes, 29 March minutes