Meeting minutes
Welcome, Antitrust and Competition Guidance reminder.
Where we are
[Ian overview of agenda in keynote and powerpoint]
Airbnb/Adyen pilot update
praveena: Background of pilot...started mid-2021
… adyen has helped immensely bring to production
… have faced multiple topics for a product like this (legal, privacy, etc.)
Praveena: Started employees-only phase end of 2021
… hit some interesting topics, like "someone didn't have their phone charged."
… goal is to open A/B testing over next few weeks with guests
… demo
… in the demo, we see a registration dialog , then platform dialog for FIDO
Renan: Really appreciate the collaboration of this project
… we see transactions being approved in this delegation setup
… we are the RP
… we think we will be able to scale our implementation for more merchants
Ian: What happens after Adyen gets the assertion and validates it?
Renan: We are doing this through network tokens.
… the token can be further validated by the issuers
… for first transaction we rely on 3DS. For subsequent ones we rely on tokens.
Carey: You had mentioned expansion to other merchants. Who might you see next?
Renan: We are discussing with a few merchants. They ask about issuer adoption.
Renan: One merchant in Germany interested.
Ian: What has made this challenging to deploy?
Praveena: From Airbnb perspective, it's ensuring that users understand what this means.
… we need to be sure from Airbnb that we had the right input data and callbacks
Renan: When I joined Adyen, most of the work was already done. :)
Renan: I think handling legal issues has been a challenge; but we are seeing program evolution so that will help with scale
smcgruer_[EST]: Have you looked at WebAuthn independently? What made SPC more interesting?
Praveena: From Airbnb perspective, we are trying to use WebAuthn for other things. Having Adyen pick up a lot from the implementation perspective has been helpful.
Renan: From a privacy perspective, and scalability perspective, we see SPC as more future-proof. And seems to be favored by schemes.
… and security benefits
Jonathan: Regarding the demo, the registration is from an iframe. That's not possible in vanilla WebAuthn.
Jonathan: the UX in the returning flow, with the transaction UX is also important to display and secure
… I think those are the two big reasons driving SPC.
SameerT: +1 that registration in iframe is valuable.
… clarification, in the demo Adyen is the RP.
Sameer: ...where is the issuer UX?
Renan: AFter the initial ID&V, there is none. It's just Adyen for transactions 2+
Sameer: And you will do different things depending on network?
Renan: Yes. 3DS is not used in subsequent transactions.
Renan: We so a 3DS challenge. We create a token with device binding. We know this returning shopper and flag the transaction as a delegated transaction.
… in the future we also plan to leverage network tokens.
Jonathan: Issuer allows Adyen to perform an authentication on their behalf.
… issuer still wants to know that the transaction has been fully authenticated; they receive that information in the auth message
Doug: I know the pilot is early on; do you have any usability feedback (even if early)?
… how did you communicate to users what it meant when a credential was created and what it would be used for?
… when additional merchants come on, how do you think it will go educating consumer about where they should expect this experience?
Praveena: I think there may be some challenges about shopping on merchant and seeing authentication dialog for PSP.com
DougFisher: How will we ensure that consumer understands...will be important.
Renan: yes, that will be very important.
Anwar: I was wondering from a bank point of view (here, BPCE), what are the implications of this model. You are allowing the merchant to register the user. From our POV, we are thinking about using SPC to authenticate users.
… we would also expect bank to enroll user.
Issue 172: Opt-out update
Jean: On our side we are still researching this on a legal front.
… when the user enrolls, we ask the user to opt-in, and we store some Payment information.
… GDPR requires that we allow you to easily opt-out, and we stop storing information.
… the chrome concerns (reasonable) were about linking to a potentially malicious page from trusted UX
… we are exploring some other options
smcgruer_[EST]: From the chrome side, something I wanted to highlight is: I view this as an optional feature that would be OFF by default.
… but optional features still have overhead.
<Ian> Here are my notes on other ideas I've heard from people:
=====
1) Upon registration, merchant communicates to user how to opt-out (e.g. via email)
2) Show opt-out information in TX dialog, but no link
3) Opt-out button in TX dialog that the prompts the user to confirm (by
authenticating) and the assertion type says "opt-out" but also is
deleted from authenticator. There is a privacy issue but only one-time.
4) Opt-out button in TX dialog and no need to authenticate.
There is a privacy issue but only one-time.
5) HTTP POST option
<DougFisher> user could be educated to use the cancel button to opt out
Gerhard: For me, this should be done where the card is *selected* not authenticated.
… what makes this complex is that there are three participants: merchant, issuer, PSP who doesn't have a direct relationship with customer.
… but at a high level, if you want your merchant to forget your card, you ask the merchant.
… I think that this should be dealt with where card is stored, not at moment of SPC authentication.
<ChristiaanBrand> +1 to Doug
DougFisher: I agree with Gerhard. I was going to suggest that, for those who cannot do it outside of SPC, perhaps "Cancel" button would work in some cases. But agree that there needs to be an overall opt-out framework
Gerhard: We'll have this important discussion (on 5 May) about privacy and inability to understand what user has done.
Gerhard: Agree that "cancel" could lead to interactions with user about what they want to do next (e.g., opt-out)
<SameerT> canceling an authentication action vs opt-out have different impact so should be treated accordingly
<ChristiaanBrand> I will say that "forgotten" is a concept that doesn't really apply in all cases. A user certainly can't tell their issuing bank to "forget" them. So if SPC is invoked that way (because their registered with their issuer), I'm not so sure that a "opt-out" would even apply here. But, as stated, there are other use cases with SPC (typically, non-3DS) where it's a bit less certain.
<ChristiaanBrand> they're*
Christian: When authentication is driven by bank (e.g., 3DS challenge), the user doesn't really have an option of opting out.
SameerT: +1 to Christiaan's comment.
… opt-out should not happen during the SPC flow.
… you don't opt out of authentication in 3DS during an authentication.
… you do that outside of the authentication flow
… if we decouple, can be more flexible
JohnBradley: This mostly applies to the PSP use case (and not 3DS)
… deleting the actual credential on the authenticator doesn't seem to be the issue if the payment information itself has not been deleted.
… from a webauthn POV, the privacy issue is correlation. one argument could be that it's not important because the user has provided a payment instrument.
… there could be multiple credentials on the authenticator for the PSP.
… we'd have to know which credential of multiple needs to be decoupled; that's the hard part
<ChristiaanBrand> the exact text doesn't actually have much to do with privacy as far as I recall: it's more about not giving a merchant the right to be able to charge a customer using a payment card on file in perpetuity. so, in other words, if this credential isn't used for payment, but rather for authentication, I do wonder how much of it actually applies
Christiaan: We looked at this a little bit. I think some clarification is needed. My interpretation of the requirement is to not have information stored in perpetuity.
… if the information is PURELY for fraud reduction, the question is whether GDPR really applies. We at Google would like to know this; relates to other use cases as well.
Jean: We are trying to reason about all these things.
Jean: You can argue that if the card appears again, the user is already re-sharing the information.
Ian: Re 172, please continue to weigh in on GitHub
Implementation update
smcgruer_[EST]: Update today on SPC implementation in chrome
[Stephen walks through timeline of SPC implementation]
smcgruer_[EST]: Android implementation relies on discoverable credentials; more on that in a moment
… in iOS need to use Webkit so don't have support yet.
… implementation has been stable recently.
… here are the recent changes:
* Added RPID as required input
… this was needed for proper intro with FIDO/WebAutn
* We added iconMustBeShown [optional]
* We added payeeName [optional] to be used with/instead of payeeOrigin
… the new inputs are part of the signed data in the assertion
… these should be in M102 stable later in May
[Upcoming changes]
* Currently chrome caches SPC credentials. (local storage specific to one instance)
… this creates a mismatch with authenticator-stored data.
… this implementation limits use of a credential to a specific browser, and we can't distinguish 1p and 3p use cases
… so the plan is to add a cross-origin bit at CTAP level, at creation time
… and that bit would be available from various APIs (allowing view of credentials 'ahead of time')
… we have raised this with FIDO; we will also need platform authenticators to expose this bit
* User activation for registration
… this is being added to improve privacy...the user has somehow interacted with the iframe recently
… I expect it to land in M103. Technically this is a breaking change, but so far as we know, everyone using SPC today already requires the user to click to create a credential.
SameerT: Regarding that change...is entering something as a challenge the same as clicking?
smcgruer_[EST]: Great question.
SameerT: Suppose user enters some data just before (e.g., OTP)...do they need to re-click?
smcgruer_[EST]: Typically the browser doesn't know what the button said. I will get back to you on whether typing constitutes a user activation
ACTION: smcgruer_[EST] to research whether typing information in a form constitutes user activation
smcgruer_[EST]: Another change upcoming is SPC on Chrome Android.
… Android doesn't support discoverable credentials today.
… but we think we have a path for getting SPC on Chrome Android without discoverable credentials; no promises but would love to see a Q3 launch of this.
… I still don't have any idea about discoverable credentials on Android
smcgruer_[EST]: We are still committed to finding an opt-out solution. We do think of this as optional.
DougFisher: Regarding an implementation without discoverable credentials; what would a change to the SPC spec look like (with 3DS spec in mind)
smcgruer_[EST]: So far our thinking is that this would not be a breaking change, and most likely not have an impact on the 3DS integration.
… when you create a credential you have to say "I must have a discoverable credential". So the SPC change could be to allow non-discoverable credentials
… we might decide to do this differently to smooth over the differences
[The Future]
smcgruer_[EST]: We are thinking about some additional icons in the transaction dialog
… we have some discussion this week about the experience when no credentials exist
… we'd like to see support on other platforms
… at some point we'll come back to the question of the API shape itself (e.g., independent of Payment Request)
smcgruer_[EST]: We do have a concern - status of SPC adoption.
… state of adoption relates to future work
Ian: Windows news?
smcgruer_[EST]: I think Microsoft as a platform authenticator have made credential listing APIs available in a dev build.
… we hope this will be a springboard for our 3p payment bit
Gerhard: Exciting journey; would like to see more progress.
Gerhard: I think having Android adoption would push us over the edge to deployment.
Gerhard: We've deployed a FIDO server, but there were challenges with permission flags. I think WebAuthn in iframe would also help drive adoption
… we see Safari Tech preview should include permission bit in iframe; that's good news
Gerhard: A third thing that we look forward to is shared credentials
smcgruer_[EST]: We appreciate that feedback! Hearing Android support is critical is good to hear.
smcgruer_[EST]: Regarding FIDO and payments; I've been wondering whether we should collect our requirements in one place
Ian: We did a bit of that previously; see the
Joint WebAuthn/WPWG wiki where we discussed a few topics. Two concrete results of those discussions: (1) WebAuthn Level 2 supports cross-origin get and (2) SPC. We can, of course, continue those discussions and will do some of that this week.
SPC Demo by Modirum
Sami: Thanks for inviting me today.
… I'm hearing with Melissa and Kenneth for technical questions
… Modirum has a test merchant "Coffee House"
… this is the only "fake" part of the demo....the rest are real (ACS, Directory Server, etc.)
… this demo shows "merchant-driven SPC"
… the cardholder challenge happens in the merchant environment
… the demo has some switches for testing purposes (the cardholder would not see these)
… demo involves TouchID on a MacBook
… I have registered previously
… we'll be using Chrome 100
[sami sets the 3DS version 2.3 and sets the SPC flag]
[The SPC flag tells the 3DS components the user wants to do an SPC authentication]
sami: First AREQ/ARES message pair happens; the merchant receives SPC credentials from the ACS. The merchant then calls SPC and then transaction dialog is shown by Chrome
sami: I timed out since I was talking, and the fallback behavior as you see is OTP
Christiaan: Is the timeout for demo purposes, or production?
sami: My understanding is that is for test enviornment.
<SameerT> that's perfect demo of how ACS initiated SPC can use fall-back
Melissa: This is an open discussion for EMVCo folks; whether implementation specific or standardized
[sami does transaction dialog and TouchID]
Sami: Second dialog briefly shown during second AREQ/ARES pair.
… the ACS does the validation of the assertion
Sami: We are getting a lot of requests from our issuers to learn more about SPC, and 3DS support,
Sami: Issuers see SPC as "the direction where the world is going"
… but if the cardholder is unable to do the FIDO authentication, they'll need a backup
… some way to authenticate
… the fallback we are using is OTP
… our implementation supports a fallback flow
Sami: In case of timeout, we send another AREQ/ARES with transaction status and that leads to usual challenge.
Melissa: Right, we send a flag that says "merchant was unable to perform SPC"
… the issuer can then trigger the challenge
… if SPC is successful, merchant passes assertion data (via ARES) and issuer validates
SameerT: I thought that it was CREQ/CRES
Melissa: CREQ/CRES is for issuer initiated; this is merchant initiated
smcgruer_[EST]: I was also confused about that point. The iframe that we see is NOT an issuer iframe; it's just an iframe to isolate 3DS processing.
sami: if the transaction is 3DS, my understanding is that the iframe needs to be present; you see the merchant open a box for 3DS transactions.
smcgruer_[EST]: Who is loaded initially in the iframe?
sami: Merchant-side 3DS server shows the logo etc for the first AREQ/ARES
smcgruer_[EST]: And if SPC fails, redirects to an issuer challenge
sami: If it fails, or if cardholder does not have an SPC-registered credential, or, say, it's an older 3DS implementation, then the issuer gives the merchant the relevant URL for the ACS
Melissa: The AREQ/ARES does not have to be in the iframe. Our implementation does that.
… the requirement is to show the logo and spinner
smcgruer_[EST]: Thank you
SameerT: So, to summarize:
<SameerT> Merchant initiated SPC : 2 AReq, ARes. Iframe is not necessary to be shown
<SameerT> issuer initiated SPC: the SPC flow is triggered from the iframe issuer has opened for the challenge part of the flow after initial AReq, ARes
Ian: What's going to happen with issuers?
Sami: We have told issuers that we are waiting to see what happens with other major browsers and operating systems.
Sami: What we have seen is that smaller issuers are in the process of finding new ways to distribute authentication methods to their card holders
… they are really interested in learning more about SPC.
… I think we'll see pilots with more browser support
<Zakim> smcgruer_[EST], you wanted to ask about Android importance for Modirum
smcgruer_[EST]: Regarding "other browsers"; how important is Chrome on Android?
Sami: We've not heard about it from banks about mobile browsers, but we understand that traffic is increasing
SameerT: A lot of merchants also use Webview for 3DS authentication.
smcgruer_[EST]: Good to know!
Ian Regarding Webview capabilities; please note the recent launch of a Webview CG to try to make progress. Not sure if Webview includes support for native chrome dialogs
Christiaan: I think that there is some flexibility. WebAuthn has been out of Webviews but there are discussions about being added back in
… another issue is access to only one origin from an app
… interesting topic is a native implementation of SPC (pure native)
Sami: Regarding merchant-side and issuer-side SPC: if the merchant is using 3DS pre 2.3, merchant side initiation is not available.
… that means just one AREQ/ARES pair.
… and so the UX is to direct the user to the ACS, where the ACS itself can do SPC [we are in the CREQ/CRES challenge phase at this point]
<SameerT> This can help with the adoption (issuer initiated SPC) in near future
<bdewater> not sure what the exact numbers are, but at Shopify we def see a lot of mobile commerce happening. some merchants build custom apps (eg AR to try on shoes virtually) as well
bart: From Shopify's end, we see a lot of mobile commerce happening are "mobile only". From that front we need mobile.
… webview may or may not be needed
Next call
26 May