Meeting minutes
See also 13 September minutes.
Welcome
NicK: It's great to be back in the room together. Thanks to those who came to Vancouver and also to those joining us remotely.
[Nick does a quick reminder of health requirements, linked from Agenda, as well as the Antitrust reminder.]
Nick: Just want to pause to celebrate PR API => Recommendation last week.
(Ian: We'll hear more tomorrow on this and discuss next features)
[Quick round of introductions, both remote and in person]
Airbnb/Adyen SPC pilot update
Peter: Thank you. We'll start with an update on the pilot we've been running with Airbnb
… to start with, why SPC?
… 5-9% drop-off rate with 3DS challenge flow
… so we are looking for a PSD2-compliant solution that lowers drop-off while keeping low fraud rate. We want a better experience for the consumer.
… our first year was limited pilot (one issuer, friends and family)
… starting in Sep we want to open to all Airbnb users for a set of issuers.
… some challenges:
1) Generic error handling
2) How to distinguish canceling SCA v just an error.
3) Educating shoppers
Renan: Shoppers see a new screen in their checkout flow
… just as 3DS learned previously, the UX of this screen is very important.
… need to tell shoppers this is easier and faster, and connected to issuer experience
NickTR: In which step are you using the errors?
Peter: Those issues were more early on
smcgruer_[EST]: These ambiguities are inherited from the web authn security model
… we probably can and should do more in the dev tools
… we can tell developers in the dev tools because it's their own machine.
… it may not require standardization
… this would help developers understand "what's going on" during the development process.
smcgruer_[EST]: I think we can do better for devs but I think we can also do better "in the field"
SameerT: In the 3DS ecosystem, issuers need to know what happened in authentication. If they can't tell what went wrong, they may be less inclined to use this as an authentication method.
SameerT: Is the pilot a delegated auth model?
Renan: Yes, Adyen is the RP
SameerT: So for issuer education, are you interested helping them understand the assertion data?
Renan: Adyen collects the assertion, we want issuers to help communicate to users this model
Sameer: We may have to break it down in more detail; the issuer may not know you are trying to enroll the user.
… suppose issuer sends me a OTP; at that point (pre-SPC enrollment) the issuer does not know that a new enrollment will happen
Renan: Right, we want issuers to help users understand that these delegated flows are not scams.
<dcrousso> test
nicktr: I assume the trust relationship between issuer and acquirer lies outside of the world of w3c
… these are commercial relationships.
Sameer: You are mostly right, but see the FIDO white paper on what FIDO data can be consistently sent into 3DS .
Doug_F: In the current pilot, the merchant/PSP is the RP. Are there future plans to extend the pilot to when issuers can be RPs.
… do you at Adyen see the longer term approach being delegated?
Renan: We envision that we will be the RP
Renan: We see this similar to liability shift patterns we've seen previously
clinton: I've heard people comment that they'd like to have help from issuers on X, Y, Z. Could we summarize those points?
Renan: We can show some of this in the demo
[Demo]
Renan: Issuers can let cardholders know that this sort of enrollment UX can occur to minimize surprise
… they can tell cardholders that this is a possible flow.
Praveena: People are used to OTP and need to be educated that biometrics can happen, and that they are secure.
Renan: This week are are rolling out an updated pilot to expand it.
… will include more issuers
smcgruer_[EST]: Note that the enrollment UX never shipped (this is an old video)
… the reason was that PSPs wanted to control the content.
… but if there is value to educating users through consistent language and UX, is there value adding it back?
SameerT: In registration, do you envision that you can provide enrollment as an out-of-band feature (not during the transaction)?
Renan: Do you mean that they user did not opt-in during flow but we can prompt them later?
SameerT: I'm thinking instead that the transaction completes, and then the user sees an optional button to enroll. And at that time the PSP has full control over the language presented to the user.
Renan: That's an interesting idea.
Sameer: There are a couple of benefits (1) user has no concerns about their actual transaction (2) it's a separate journey that could be made clear to the user.
Renan: Yes, that makes sense
Sameer: 3DS 1.0 had "enrollment during shopping" which was considered bad. The transaction took too long and errors messed with the transaction.
… so we dropped that flow.
… if you enroll outside the transaction you are clear of 3DS limitations today
<careyf> +1 to sameer's point
nicktr: Another SPC registration moment could be at the moment that the user provides a card-on-file to Airbnb?
Renan: We do need some ID&V [with the issuer]
… so we leverage the 3DS challenge for that
… before that we cannot trust the card with this device
… we use 3DS2 for device binding
Nick: Any more to say on trust model between PSP and issuers?
SameerT: Some of the trust comes through standardization in 3DS.
NickTR: There are fewer risk providers than issuers.
clinton: Regarding delegation, are your questions related to SPD2?
Nick: Yes, that's where I'm heading. At the moment we have provided a strong signal to issuers where they don't have to do a step-up
… what I'm hoping to do is achieve a technical link between assertions signed by delegated RPs and the issuers.
… can there be cryptographically established delegation
JeanLuc: In 3DS there is a place to tell the issuer not to do a challenge.
… so there is a place for the merchant to share information
… but there is no place to share the SPC attestation
… could that be useful?
Ian: I think that's available in the FIDO/EMVCo model
Sameer: The question is whether the data could be made available.
smcgruer_[EST]: If WebAuthn has it, it would be available
ACTION: smcgruer_[EST] to check whether the attestation is available during SPC flow
JeanLuc: I think there is no way to carry the information in SPC context.
careyf: In the pilot, does Adyen own the issuer relationship?
Renan: We as a RP have to fulfill scheme requirements
SameerT: Regarding attestation, we can consider that in future 3DS revision
smcgruer_[EST]: For delegated auth today with 3DS is there a field for attestation?
SameerT: You have a place for attestation and/or assertion
Doug: In the case where the issuer is the RP, the issuer already has it. If the merchant in the RP, then I think there is a gap.
<JeanLuc> 3DS threeDSReqAuthData field could contains SPC attestation from merchant delegation flow. therefore, issuer could perform risk analysis and recognized the authenticator behind
ACTION: Sameer to see about enhancing 3DS flow to include attestation if available in SPC context.
[Peter, Renan leave]
SPC on Android
smcgruer_[EST]: I'm the primary editor of SPC spec and lead this work in Chrome. Here's an update on implementation.
smcgruer_[EST]: the thirdPartyPayment extension has landed in CTAP2
… no immediate impact but good foundation
… still work needed to figure out the story for remote authenticators
smcgruer_[EST]: We also renamed rp->rpid and we'll do both fields for some period of time (3 milestones)
smcgruer_[EST]: We started origin trial with opt-out (optional) feature
… the opt-out relates to RP storage
… this relates to interpretations of GDPR
… the payment request error indicates opt-out, and then the caller's responsibility is to share that with the RP
… we ARE contemplating changing the message to "successful opt-out" instead of Abort
smcgruer_[EST]: We are in discussions with Web Auth about allowing cross-origin create()
… we want to move this into Web Authn for all credentials.
… I hope we'll have robust discussion tomorrow on this
smcgruer_[EST]: Regarding SPC in Android, we changed both spec and implementation to allow resident keys
… I don't know when Android will support discoverable credentials.
… we still need to add opt-out and a few other things, but you can try it out today
smcgruer_[EST]: Why did it take so long to ship on Android?
… the main reason has to do with the browser caching information about credentials as being special for payment
… (the feature that is moving to CTAP2)
… this caching approach is per-browser, limiting reuse of credentials
… several problems including both false negatives and false positive.
… it also doesn't support the "first party payment" use case for SPC
… so on android, we added OS-level credential support
… chrome tells android to mark the credential as a 3p payment credential
… some consequences this approach:
a) works for first-party context use case
b) Third party payment is no longer browser-scoped
smcgruer_[EST]: We change the OS API to support thirdPartyPayment bit
… we have built on top of listCredentials(rp_id); and the browser also gets back the thirdPartyPayment bit.
… so the browser looks to see whether it's a 1p or 3p context, whether the bit has been set, and after filtering decides whether there are matching credentials
[SPC Demo on Android]
smcgruer_[EST]: You can turn on a flag today and do this yourself. But not yet shipped: opt-out support.
… also not yet shipped: 1p use case
[Nick tries out the demo to show that it works on his phone]
smcgruer_[EST]: What's next?
… should we ship opt-out?
… we don't love it as a concept; we need to hear clear demand from people who are going to use SPC.
… we want to use authenticator level APIs on more platforms; we need to engage with Microsoft and Apple
… there are other UX challenges, and "no matching credential / privacy" tension
JeanLuc: Regarding the platform, you said browser would invoke get list. Is there any reason why there is not a parameter to add rpid?
smcgruer_[EST]: We don't need the list credential API fully; it exists for conditional UI.
smcgruer_[EST]: We are thinking about moving the API further into Android. We might be able to enable SPC in web views...if we bake it into Android.
smcgruer_[EST]: And similarly, if we push this into the OS we could enable SPC for Android Apps
Nakko: Great to hear porting to Android. If a browser can access the credentials, could other apps access the credentials?
smcgruer_[EST]: No; we have a list of trusted apps (browsers)
… we probably could have it work for your own origin (e.g., if you are the app for bank.com) you probably could have the credentials for your own origin
… but if we wanted to do this cross-origin, we'd need to build it into the OS
Nakko: I am thinking about merchant app accessing credentials from the 3DS SDK
smcgruer_[EST]: Yep, we'd need to build into the underlying OS
javad: What is the retention policy for user database?
smcgruer_[EST]: User can clear it
… I don't think there's a retention policy. But the data we are storing is non-sensitive data (e.g., the public key)
Javad: If you put the data in the db, how do you sync for multi-device scenarios?
smcgruer_[EST]: That is what passkeys address. there are ongoing discussions about device public keys
FIS/Worldpay use cases
Brant: Want to talk about payments use cases and also broader reach within this community
… one goal is to re-introduce FIS to W3C community
Brant: FIS has a merchant processing channel, issuance channel, and user-facing wallet
… represent 4000 financial institutions (some smaller, medium)
… we have a consumer-facing wallet (GoCart)
… we have a growing network of consumers using this wallet
… branded GoCart, which is integrated into FIS merchant processing
… we are also planning to expose to non-FIS acquirers
Brant: We hear a lot about three main use cases.
… first I will call the post-pandemic reinventors
… these are shops that want to transition from shopfront to digital first
… key to their strategy is about using their brand as their key strength for their digital strategy (e.g., expansion of subscription options)
<Zakim> nicktr, you wanted to ask about geographic coverage of these personas
nicktr: Is this global or US-focused?
Brant: This one is particularly US-focused
Brant: Most of our customers use multiple PSPs globally
… I am mostly focused on US here.
… Vantiv (our original brand here) was historically focused on big box retailers
clinton: Regarding identification of shoppers, you said people wanted to identify their customers pre-authorization; how far in advance?
Brant: I mean "before the authorization request is submitted"; if the customer can identify the customer before that they can apply discounts, for example.
Clinton: These are shoppers that don't have accounts?
Brant: Right, they could be doing guest payments, or using alternative payments, etc.
… loyalty is hard to reconcile after auth message.
Brant: The second main use cases is focused on "seamless shopping experience"
… they want personalized checkout experiences for their shoppers to avoid abandonment
… these are not focused on their own brand
… focused on UX
… so optimizing for mobile browsers, increasing conversions through analytics, etc.
… e.g., they have data on how latency leads to abandonment.
… they are interested in things like "one-click" payments.
… interested in whether they have seen the shopper previously to create a more consistent UX for the user
Brant: Third use cases is those seeking strong control over their checkout experience.
… they don't want to look like everyone else.
… they want full control and detailed control.
… they are not as interested in standards since they want to distinguish themselves.
… they know their shoppers better than anyone else.
… many in this top 15 segment have co-branded cards as well
… they want some optionality to accept, e.g., government-supported (in the US: Snap) cards
<Zakim> nicktr, you wanted to ask if ebt cards are cobranded
nicktr: Are EBT (snap) cards co-branded?
Brant: They are closed-loop pre-paid cards (e.g., issued by FIS or FISERV)
… they are not co-branded
Nick: Are they EMV-style cards?
Brant: No
… we started to want to enable EBT for COVID to enable more users to be able to shop without having to go into stores.
nicktr: There is a connection here between underserved population and the mission of W3C
JeanLuc: to avoid "declines" is there space here to help merchant understand "declines" and help the merchant to try a second authorization request.
Brant: The one challenge we have is that we get back generic declines.
… we are starting to look at potentially dozens of decline messages to find more cases.
Brant: Some key customer themes.
1) Merchants want to know who their customers are prior to authorization
2) Data is not always available based on payment types or implementations
3) Cart abandonment is a problem due to extra friction and payment problems.
clinton: Regarding using payment credentials as representation of shopper. Do you see merchants using PAR?
Brant: I think PAR can be effective. But it may not solve all use cases (especially if it only happens post-authorization).
… PAN is useful today even if not the right thing for the future.
… for risk mitigation not sure PAR is enough; we've seen up to 50 tokens associated with one PAR.
… if you are a merchant, I'm not sure they have the same resources to do the sort of AI used for fraud mitigation.
… I think if we could get PAR before authorization, it could help.
… could help to get access to PAR outside of payments flow
… the value is perhaps there, but implementations may need to be enhanced to get us there.
clinton: I don't know that PAR is part of SPC.
smcgruer_[EST]: No.
[Pause to revisit the origins of tokens and PARs]
Ian: Not sure this needs to be specified in SPC. I don't know whether 3DS field for SPC would allow use of PAR v. PAN
clinton: I am hearing value in getting the PAR into the ecosystem.
Brant: Yes, that's step one.
clinton: It's not consumer level; it's account level
Brant: One use case I'd like to discuss that's creating some issues for our merchants is using tokens with auto-fill.
<Zakim> nicktr, you wanted to ask about storage
Brant: There is clear value to tokens. I want to communicate feedback we are getting, and to discuss whether there are standardization opportunities here.
… tension here is between security and UX
… merchants lose ability to create customized experiences.
… e.g., post-authorization analytics, chargebacks, etc.
… they all rely today on representations of cards that don't work with tokens
… and merchants concerned about losing debit routing abilities
… merchants will resist some of the capabilities if they are unable to adapt
<Zakim> nicktr, you wanted to ask about autofill
nicktr: Is there a web standard for autofill?
(No)
Devin: You can turn off autofill in HTML, but how it works is implementation dependent.
Brant: Our merchant community can take a scorched earth approach, but it degrades the shopping experience.
Devin: I would happily see autofill be standardized, but even better is when web sites do the right thing
smcgruer_[EST]: +1 to Devin.
… there may be some more work over next few years to do more work on autofill.
… but work is stymied by wrong use of html attributes
Devin: Although HTML has a decent level of semantic information, more would help.
… but also don't want to large of a set of input types.
nick: My understanding is at least google and possibly apple are becoming token requestors.
… they get back a token pan scoped to the device and the browser (I am speculating)
smcgruer_[EST]: I think it's browser-scoped, not device scoped
nicktr: You could get PAR on that token request
clinton: Yes
Brant: Also here would like to ask -- what can FIS/Worldpay do more to take an active role within W3C?
Ian: Does it make sense to work on an experiment to get pre-Auth PAR by working with browsers and TSPs?
Brant: Yes, that would be a good action.
Microsoft perspectives on SCA
Dean: I am part of the payments team at Microsoft. I was responsible for the authentication program in Europe
… Microsoft is a global e-commerce merchant
… do sales with credit cards, alternative payments, etc.
… lots of countries and currencies
… both business and consumers
… both one-time sales and recurring
… digital goods and physical goods
… we implemented 3dS v2 back in 2019
… we have not built support for exemption flagging or soft decline.
[On SCA]
Dean: The frictionless option in 3DS makes a big difference in the UX and business result.
… the take away in terms of impact is that we've seen a net negative impact at Microsoft
… because SCA performance is poor. Challenge rates are high; authentication success rates are low
… the ecosystem was not ready, in our view, to leverage the flexibility allowed by EU rules
[Data on Microsoft authentication]
Dean: We have distinct implementations of 3DS for our web-based scenarios (where a user is visiting an MS storefront from a browser) and MS Console (where we have an SDK)
Dean: Especially early on we saw a big difference in performance on Consoles (75% success rate) and Web (67% success rate).
… performance in the UK was much better than the average.
… so the 3DS experience differs depending on the issuer community in a given country
… the numbers I'm showing are a "first attempt"
… In EU or UK, 1/4 fails on the Web first time
… when first attempt fails, users may retry or switch to a new payment method. Success rate does tend to improve with 2nd attempt.
careyf: Did you only implement the additional step-up in the UK and EU?
Dean: We've tested in some other markets (e.g., Mexico)
… we do 3DS v1 in India
… but Europe with some experimentation in Australia and Mexico
… the reasons we are looking at 3DS in the other markets vary
… in Brazil, if you enable 3DS you can accept debit cards online
… in Mexico, we are unable to challenge or re-present chargebacks. Authenticated transactions give us a way to deal with that unusual situation.
benoit: In markets like India and Australia, do you have comparisons with other methods (e.g., UPI)
… is the issue the buyer or the method?
Dean: What we do in Australia is we randomly enable authentication for a small percentage of transactions (e.g., 5%)
… in a legitimate experiments, people could compare results with/without authentication.
… however, in India we have not implemented UPI and don't therefore have a comparison.
… what we did in Europe (which allowed us to draw conclusions) is compare historical trends for cards with PayPal.
… we lost 2-4% in conversions with SCA
… that's settled down a bit since the initial measurements.
Fahad: 2-4% at authentication step (rather than authorization)?
Dean: Yes.
Fahad: Do you have any significant changes in authorization?
Dean: With transactions that have been successfully authenticated, the authorization rates go up, which is great.
… but that has to be balanced against abandonment when authentication fails.
… when looking at both of those, SCA was a net negative for us.
<nicktr> ack
Dean: When I talk about authentication success rates being too low, let's look at the components.
… Authentication Abandonment Rate (which I'll talk about in a moment) is measured in terms of 3DS protocol messages
… we see 12% abandonment on the Web (for EU + UK)
… we see high challenge rates as well: 68% of transactions on Web (EU ex UK)
… in the UK, the banks keep the challenge rates relatively low (28%) compared to the rest of Europe.
Gerhard: SCA is two factor. Many other markets have single factor auth. Do you see differences in abandonment rates between single factor and 2-factor on the challenge itself?
Dean: I don't have any data to share, but I could speculate that there is more success when less friction.
… this is also part of why you get such a difference for SCA over 3DS
… different banks use different authentication methods (e.g., banking app opens on user phone; the user just pushes a button to say yes)
… some banks invested in good authentication experience; others did not
… one-time passcodes or security questions tend to lead to more failure.
… as merchants, it's the variability in issuer UX that can be frustrating.
magda_sypula: Why is the UK doing better (it seems)?
Dean: The main difference is the third column. In the UK, the majority of authentication requests will be approved or declined using the frictionless flow.
… the customer is not stepped up for a challenge. It's the lower challenge rates that drives greater authentication success.
… if you are a bank with a risk system and you have an incoming authentication request, there's going to be a small set of transactions likely to be fraudulent, so you just say no.
… and others you are obviously confident to accept
… so it's the small band in the middle where the bank is not sure where the step-up challenge should occur.
… the UI systems have optimized their risk systems to behave this way.
<Zakim> smcgruer_[EST], you wanted to ask if the lower challenge rate is due to SCA exemptions, or better risk analysis, or ...
smcgruer_[EST]: Is the lower challenge rate in the UK because they ask for exemption more frequently?
… or are purchase patterns different?
Dean: The banks in the UK took a different view of their obligations under PSD2
… supported by the FCA in the UK (the regulatory body for banks in the UK) they were given permission to take an approach where they could take a more "commonsense" approach to step-up.
… we spoke with other banks and card networks in 2020, 2021; what we found is that banks in other countries (guided by their regulatory bodies) would take a more black and white approach to PSD2.
… the UK banks were more willing to grant exemptions from the issuer side.
… the TRA exemption
Fahad: For transactions where the issuer requested a challenge, how did countries compare?
Fahad: For the 16% where challenge was requested, how was completion?
Dean: Great question. In my scorecard, cf "CSR" (challenge success rate)
… a challenge in the UK success rate about same as for France. So the difference in "rate" is due to UK doing fewer challenges.
[Strategies to mitigate PSD2 impact]
Dean: I am often asked "so what can we do?"
Dean: We should avoid authentication whenever we can.
… some transaction types are out of scope (e.g., subscriptions)
… customer-not-present transactions
… another strategy that emerged was to attempt authorization first with exemption flagging in the authorization message, and only if authorization declined by the issuer who explicitly asks for authentication, doing authentication.
… moving customers to alternative payment methods is another way to get around the SCA requirement.
… we saw an increase in PayPal volume as a result of PSD2 for example.
Dean: The second big strategy is to avoid the challenge.
… merchants can share additional data during authentication (cf the long list of 3DS fields)
… you can also do exemption flagging in the authentication request itself
… PSD2 also has a "trusted beneficiary" option where customer can opt out of future challenges.
… e.g., Amazon was interested in that to preserve one-click experience.
… trusted listing is a good example of a provision under PSD2 that is not widely implemented in the ecosystem.
… very few issuers implement trusted listing.
Dean: If you can't avoid the challenge, then look to improve challenge outcomes. Delegated authentication fits in well here.
… as a merchant we've seen that different banks have very different authentication methods. It's the inconsistency that drives a lot of the poor performance I've mentioned here.
… handing over a piece of the checkout to the issuer is something that merchants hate.
Dean: The final big strategy is to attempt authorization EVEN IF authentication fails.
… people ask "Don't you think those are fraudsters?"
… and the answer is "mostly no; it's mostly just customers not getting through authentication."
Dean: So we've got something called SafetyNet to preserve conversion rates.
… outside of Europe (except for India) you don't have SCA requirements driven by regulation.
… so as a merchant, we have an opportunity to be a lot smarter on how we do SCA and do it much more in-line with when we think there is risk of fraud.
… PSD2 has a more heavy-handed approach.
SameerT: This was very helpful. One question I have in terms of data being shared with issuers. Do you see much difference between what data is shared in the UK v other markets?
Dean: We share the exact same data in UK and EU markets.
Dean: There are different risk systems for authentication v. authorization. The ACS risk models (for authentication) are not as mature as the card network models (for authorization)
SameerT: This data is very helpful; we are trying to define a roadmap for 3DS to ensure that risk models get enough data to avoid challenges.
… cf other conversations at W3C about data collection from the browser.
Gerhard: Would SPC be interesting (e.g., because merchant controls UX and issuer can validate assertion)?
Dean: This is a super interesting idea and something that I'm still learning about.
… the idea is appealing. If we have an approach that can tackle either the fact that, today, customers have a poor experience with their bank, that would be great.
… and if we have a way to lower the challenge rate, that would be great.
… so we want both better experience for customer and lower challenge rates.
Gerhard: I perceive a difference in which authentication mechanisms are used between Web and native apps.
… do you think issuers are concerned about that?
Dean: It is an important consideration. You have merchants that are fully app-based (e.g., Uber) and so, from an issuer perspective they are going to need to support both.
… if we are asking issuers to support a standard and that standard only targets web but not native, it lowers the ROI of that solution investment.
Dean: App experience can be the best experience (app-to-app). The SDK flow can't be ignored.
JeanLuc: Regarding "avoid authentication". Regarding MIT/MOTO out-of-scope transactions...this is being re-evaluated and it may be complicated in the future.
… for "authorization first with exemption flagging" ... we've started to see some penalties from issuers in the fact of soft declines.
… you observe that some merchants are reluctant to share info through 3DS due to sensitive data.
Dean: the way I think about your comment...a merchant can't have it both ways. We can't complain about an issuer doing a high challenge rate if we are not giving the issuer information necessary to make a frictionless decision.
… we would ask the issuer community to make it clear to merchants what the important fields are for issuer risk systems
JeanLuc: Maybe requirements in 3DS change based on availability or lack of other fields.
Dean: I don't think that EMVCo as a standards body would likely be that perspective. I anticipate it would be more from the card networks providing guidance on how to get good authentication performance.
Bastien: As much as I love the conversation here, there's plenty of space for providing feedback directly to EMVCo.
NickTR: We'd love for you to implement SPC!
… thanks again for the great presentation
EMVCo on SPC / Demo
Doug: We're going to provide some EMVCo feedback on SPC.
… feedback is mostly about how to handle some new category of transactions (e.g., subscriptions)
… there's a lot of focus (e.g., in EU) on increasing the transparency of payment authentication when it involves asking users to enter a recurring transaction.
… users may not always be aware of what they are being asked to consent to
Doug: In the transaction dialog we'd like to see more branding (so user understands context), an explanatory note, a larger icon.
… we also want to extend SPC to handle non-payment use cases.
[Doug lists some use cases]
Doug: Different parameters that can be set independently:
* Amount (which may vary)
* Frequency
Doug: We'd like to be able to use SPC when recurring transactions occur; we see that segment growing
… another use case: I order 10 pieces of clothing and have one month to return some of them and I'm only billed for those I keep
Doug: Another use case is variable amount/variable frequency (e.g., travel card)
Ian: Could you create an enumeration rather than arbitrary text?
Doug: That's really hard given use cases as well as other nuances like language differences.
… in the 2.3.1 specification we have added a freeform text field to support this use case.
nicktr: How commonly is 3DS2 being used to authenticate these recurring transaction use cases?
<Gerhard> Comment: Open Banking specs and EMV QR has 'codified' some of this variability. Could we perhaps use that?
Nick: Is this a rarely used bit of the spec? I'm not aware of many acquirers or issuers who would use this commonly.
… is this commonly done today or emerging?
Gerhard: We look at open banking specs and they have a number of parameters around recurrence (as Ian was hinting). And the EMVCo QR spec has some parameters as well.
Gerhard: I can see this working well for a subscription service.
… or "would you like to trust this merchant?"
or "Would you like to have your card stored on file with this merchant?"
… but I would be worried about very open consents ("any amount, any merchant", etc)
ChristianA: In the EU they've said "it happens a lot, but it doesn't happen in the right way"
… so European Union came to us to find solutions
smcgruer_[EST]: I think it is a very unlikely world where we will put arbitrary text in a secure dialog.
… but I'm excited to hear the appetite for this.
… if we can codify this in any way to hit 80% of use cases, that's much more palatable.
Rose__: Regarding use cases and commonality; this does arise. Prices changing based on tax computations is another use case.
SameerT: Could we define a set of use cases, e.g., "Travel", "Subscription"
smcgruer_[EST]: Our UX people will want to write the actual text.
… regarding translation, the Web site and your Chrome UX may not be in the same language.
Gerhard: I think there are three categories of use case:
1) ID & V
2) Payments
3) Consent about other data
<Zakim> Ian, you wanted to talk about consent functionality in WebAuthn
Ian: I will add "sign what you see" to tomorrow's joint meeting
[Non-payment transactions]
Doug: What happens if we pass a "0" amount?
(We confirm payment request would allow this.)
Doug: We'd like to allow authentication for future payments. It would be good to suppress the 0 amount in this case.
smcgruer_[EST]: This gets to the point of "scope of SPC"; we've gotten support from the WebAuthn approach for our limited payments use case.
… I'm not sure whether right vehicle is SPC or something else; we need to coordinate with the WebAuthn folks.
[Branding]
Doug: We think we need more branding so that people understand to whom they are authenticating.
… to the extent that there could be consistency in branding between the transaction dialog and the 3DS dialog, that would be helpful
smcgruer_[EST]: These are valid observations. There is certainly one verifiable bit of information (RPID) but that's not branded.
Ian: Does it help that images can be validated?
smcgruer_[EST]: No; the RP could be malicious.
Gerhard: Are there niche industry use cases that are relevant here (e.g., travel, hospitality)
… I recall extensions for travel and hospitality
SameerT: I don't think those extensions are relevant here.
<Zakim> Ian, you wanted to be sure we are tracking the issues
https://
[We validate that all the issues raised today are in the SPC issues list]
[Demo]
[Demo where there's a timeout in the transaction dialog]
<Gerhard> Dropping off as nearly midnight on my side. Enjoy the rest of the sessions! And thank you to all the presenters.
SameerT: Can you run through the merchant-initiated flow?
SameerT: Does clicking "Confirm purchase" constitute a user activation?
smcgruer_[EST]: If SPC is called from merchant domain, then it suffices.
… if you were looking at the case where there's an iframe, if you have an issuer button in that case, that would constitute the user activation.
SameerT: What about where adyen takes you to their own domain?
smcgruer_[EST]: You have two options. Suppose Adyen opens an iframe in the airbnb domain. There's a way to delegate the user activation from airbnb to adyen. If this is not done, then Adyen would need to have their own user interaction.
… I think that's how they are doing it these days. It does allow the PSP to offer alternative authentication approaches as well.
SameerT: In 3DS we do well merchants what they need to do; might need to say more to them about user activation.
smcgruer_[EST]: An advisory note might be useful. But in the case of issuer initiation, you probably don't want to recommend that the merchant delegate a user activation to the issuer.
SameerT: The merchant doesn't yet know whether the issuer is prepared to do SPC. So the merchant (which does know it wants to do SPC) may need to do the user activation even if it ends up not being used.
smcgruer_[EST]: The only reason SPC requires a user gesture is that payment request requires it. But WebAuthn.get() does not require a user activation.
… but I can see a world where people don't require a user activation
SPC getting to CR
<smcgruer_[EST]> https://
<smcgruer_[EST]> https://
https://
<smcgruer_[EST]> https://
<smcgruer_[EST]> https://
Ian: It would be great to get feedback from Apple on the standards position, and if there are a small number of suggestions, I expect the WG would like to get them done in V1
[Nick does a review of the W3C process states]
ian reviews future SPC requirements
ian: https://
<Ian> https://
ACTION: smcgruer_[EST] to get info on priority of more icons in transaction dialog from design team
ian: issue 187 is about providing clarity about the relationships between the various parties in an SPC authentication
ian: 186 is non-payment use cases including "zero value" authentication
… so it would be good to understand what we need to display
doug: this steps us into the use case for where the initial payment is zero but the recurring payment is non-zero
<Ian> https://
sameerT: adding a card to a wallet is another good example of this
smcgruer_[EST]: could you do this with your own UI and webauthn?
SameerT: yes
smcgruer_[EST]: SPC enrolment is the same as webauthn - the only difference is the extra payment bit that gets set
… so my challenge would be that webauthn should be used
clinton: which credential are we talking about?
… the SPC component is just about giving the merchant additional reassurance
<Ian> smcgruer_[EST] use case: re-prove your identity when adding an existing credential to a wallet; is there value with user consent that they added a card?
ACTION: Sameer to work with the 3DS WG to write down in more detail the "non-payment transaction" use case.
<Ian> [ADJOURNED]