Meeting minutes
Updated on issue 172: Opt-out
https://
Stephen: Regarding 172, Stripe suggested that there be an ability for the user to let the RP know to remove stored data (for GDPR)
… Proposal 1: Stripe suggested a link to the RP domain
… Chrome Team is concerned about that approach, concern that secure UX could be seen as "endorsing" link to (potentially malicious) RP site
Stephen: We don't want a situation where, e.g., RP phishes (e.g., for card numbers)
Stephen: Proposal 2 is for user to stay in the browser experience, but browser sends a signal to the RP (e.g., an assertion)
… the RP does not get card information; only gets an assertion
Stephen: Both proposals involve complex UX; we are looking for input from people on whether these work, and whether opt-out required at all
Rolf: You need a way to delete an account. Not sure the link needs to be in the SPC dialog
IJ: I think problem in delegated flow is that the user does not know the RP.
… user doesn't know Stripe. User knows merchant or bank.
Rolf: To whom is the user authenticating?
Stephen: It is Stripe (in this delegated flow). Merchant A hands authentication to Stripe who is the RP
… so Stripe stores data. But the function of Stripe here is often invisible to users.
Rolf: Payment processors exist today. Users can tell payment processors "forget my data"; why isn't current deployment inadequate to the task?
… it may be the merchant's responsibility to give link
Stephen: So a third alternative is that this opt-out should happen outside SPC (with a link to the RP)
… I've heard an argument against that ... merchants don't want those links.
Jean: What happened is this - where are using our 3DS authentication to enroll credentials. At this point we need to indicate that Stripe will store information (opt-in).
… since we are allowing opt-in, we need to display (at some point) an easy way to opt-out.
Gerhard: Suppose I am shopping and I say "remember my card for future shopping" and the card is remembered by Stripe. There is a place to go to see your cards (on the merchant site)
… I think it will be tricky to do this opt-out during shopping
… suggest merchant gives access to partner where user can manage stored data
This should not be in SPC dialog; rather offered by service provider
dfisher: +1 to Gerhard's view
… at the most recent WPSIG call EMVCo provided feedback on the opt-out issue
… we don't support incorporation of the opt-out link into the SPC UI
Rolf: +1
Ian: What are limitations of approach where SPC sends assertion to the RP?
Stephen: I'm hearing the critique of proposal 1 is also a critique of proposal 2.
… meanwhile, the downside of proposal 2 is user understanding.
… does user understand what user is opting out of? And to whom?
… the browser signal is also a bit more complex to implement (e.g., RP has a well-known domain, or server is down, etc.)
Gerhard: The term "delegated authentication" as used here typically refers to the account provider (e.g., the bank) delegating authentication to the merchant / PSP
Store A and Store B should indicate that they are using a shared resource (e.g., Stripe) to make payments easier.
I think there are 3 permutations:
1) ACS can approve context in ACS context
2a) Delegated auth: Merchant A shopping and Merchant A credential. Over time Merchant A credential may be more trusted over time
2b) SPC: PSP credentials are used within Merchant B context.
Gerhard: In all cases, it's important to indicate who the RP is.
jeanluc: Key point re: delegation is who has liability. There is both "capture" and "validation"; validation here is ultimately done by the ACS.
dfisher: I did want to refer to one of Ian's comment about merchant-initiated and issuer-supported use cases. I want to distinguish "merchant-initiated" from what Stripe is doing.
… in merchant-initiated (per 3DS) the merchant is always the RP
… that distinction is important in terms of opt-out
<Zakim> Chris_D, you wanted to comment that EMVCo delegated authentication actually delegates authentication from issuer to merchant or another party; SPC is different - the issuer still authenticating the user but via a process which involves the merchant/PSP to respond to a FIDO challenge - this does impact liability shift as Jeanluc is saying
ChrisD: I want to reinforce Jean-Luc's point. My understanding of delegated authentication is that it's where the issuer delegates authentication to a 3rd party who says that they've authenticated the shopper and the issuer "allows it to happen"
… and there's a liability shift to the merchant. My understanding of SPC is that it's still the issuer who indicates whether they are happy with the response to the challenge. So it's not really delegated.
smcgruer_[EST]: First, SPC is an authentication technology that can be used by lots of RPs. It can be used in any of the above scenarios.
… so we should be clearer about saying "This is the integration of SPC into 3DS."
… but that is NOT relevant to what Stripe is doing
… Stripe is using 3DS delegation authentication ... liability being shifted from ACS to Stripe
… and at that point the merchant can do whatever they want in terms of authentication
… and in Stripe's case, they want to use SPC
… so I think this scenario is still delegated authentication.
Ian: So three scenarios:
1) ACS does ceremony + validation
2) Merchant does ceremony + ACS does validation
3) Merchant does ceremony + validation ("delegated authentication")
dfisher: Logo presentation to show who is the RP is important to user understanding.
… SPC is not dictating who is the RP, but if we can't address UX complexity in these different use cases, may not be usable
Ian: Are we hearing Proposal 3 should get more attention? (RP works in merchant domain to show user options for managing credentials)?
<Gerhard> So are you saying 'this is not an SPC problem to solve'? If so then +1
Update on issue 157: Cross-origin use of credentials
Stephen: As a reminder, this is our issue about how to integrate SPC into WebAuthn/FIDO so we can do special powers without browser cached information.
… there is a proposal on the table that involves reaching out to the FIDO Technical Working Group
… my expectation is that I will send a pull request in the FIDO GitHub repo (which is private). The API access that we want is well-served by functionality that is part of the Conditional UI proposal
… and so my colleagues have suggested that where we should focus is on the "bit" stored in the authenticator allowing cross-origin usage
… in terms of Conditional UI I expect in the short term to focus on platform authenticators to get experience then move into FIDO for remote authenticators too
JohnBradley: Conditional UI is supposed to work also with remote authenticators.
… only works with discoverable credentials (which SPC is using)
… there's a "user external authenticator" button
Stephen: I think we can do something similar with SPC. We would have a "use external authenticator" button
JohnBradley: Conditional UI itself may not expose whether something is a cross-origin credential.
… that's potentially a separate issue.
… as an example, a Windows platform authenticator may not expose that information. If Android does it would be proprietary for the moment.
Stephen: Is there a standard API for "fetch all credentials for a given RP" under Conditional UI hood?
John_Bradley: There is not and may never be.
Gerhard: Regarding the "bit". We had said 2 potential bits: (1) Enable payment display (2) enable cross-origin
Stephen: I would rather we get the platform work done (to allow things to just work)
… my assumption is "let's assume that on a platform, Chrome cannot query for credentials for a given RP; instead it can only initiate authentication."
… we need the API before we decide to show the transaction dialog
… and that's the same API that underlies Conditional UI
John_Bradley: We should get clarity on whether and when it will be implemented.
Any feedback on UA string reduction from payments community?
January discussion of string reduction
Stephen: Starting in Chrome 101 (in 2 weeks) we will no longer server minor version of the Chromium version (will be all zeros)
… there are subsequent stages of reduction throughout 2022
… will remove desktop version number
… client hint API is being introduced to get the information (but proactive v. passive)
See the antifraud use cases https://
https://
https://
jeanluc: This is an important topic
… lots of antifraud providers exploit this information (e.g., UA string)
Next meeting - remote 3-5 May
No meeting 28 April
Next meeting is 3-5 May remote meeting; see the agenda.
TPAC 2022
There was a decision that it will be hybrid; I expect a hybrid WPWG meeting. W3C is looking to ensure the A/V will be high quality.