Meeting minutes
Adding opt-out feature to SPC version 1
Pull request 215 re: opt-out feature
smcgruer_[EST]: We did origin trial on this feature and now would like to ship the feature; we need spec support for it.
smcgruer_[EST]: There is an optional parameter that is false by default, but if set, causes the browser to display an opt-out option
… if the user chooses to opt-out, we throw and error and the site processes the error (e.g., tell the user in text that once they complete 3DS that the RP will delete the data).
Gustavo: There would be a challenge after the opt-out right?
smcgruer_[EST]: Can't speak to Stripe's exact user flow. In their case, they are the RP; they decide what level of authentication to conduct.
gerhard: There are different user flows that are related: (1) cancel this authentication (2) opt-out of using this credential 'forever'
… is there an opportunity to opt-out for "this transaction only"?
… do you think there's a mismatch in the amount of detail the caller gets?
rouslan: I see where you are coming from - one "this transaction" one is "forever". However, I see it slightly differently.
… I see it more that the proposed boolean is to remove stored data (stored by the RP).
… it does not have implications about what happens in the future.
rouslan: I would prefer that this opt-out is about "removing current information" rather than saying anything about whether I might use a different credential in the future
smcgruer_[EST]: Gerhard has it right - regarding the privacy question; we haven't changed our norms here. The opt-out flow is shown on both flows (authentication flow and notification flow that there are no matching credentials); even if that's not a great UX, the option is shown on both.
Gerhard: Giving more options to cancel might lead to confusion.
Gustavo: Do we expect the opt-out need to be the same for the issuer?
smcgruer_[EST]: My understanding is that the general feeling is that when the issuer is the RP, the user knows where to go to opt out
sameer: From 3DS POV we wanted this feature to be optional
pfresent+ Makjo_Shishkov
smcgruer_[EST]: Note that there is user intent here (browser-owned message); but also message shown on both screens.
Gerhard: Is it worthwhile to have a discussion with privacy folks on this?
Gerhard: Not a good UX if I "cancel' and am shown other authentication experiences. I may mean "I want to cancel the transaction".
smcgruer_[EST]: What about on the transaction ux there are three options:
1) Verify
2) Use a different auth method
3) Cancel
… then on the no-matching credentials dialog:
1) Use a different auth method
2) Cancel the transaction
… so the 2 different "user a different" and "cancel" look the same.
Ian: What if "opt-out" only shows up after "cancel"?
Gustavo: It has to be very clear what "cancel" means (namely: this transaction)
… there may be confusion if user does not understand what they are opting out from.
… in Ian's comment, is "opt-out" shown only when credential is available?
Gerhard: It gets complicated given the number of parties involved (cf. also 3DS UX with multiple logos)
Ian: Next steps?
smcgruer_[EST]: On opt-out, I want to ask whether anyone objects to this being added? I don't think it affects other ideas we've discussed here.
Gerhard: Ongoing concerns about various options _during_ a transaction.
… I think we need to ensure customer clarity for non-happy path scenarios.
… would be good to get some bank input.
Propose: Adopt the opt-out feature into SPC v1
<cferro> +1
<benoit> +1
<nicktr> +1
Ian: Not a lot of +1....any reasons people want to articulate to not adopt?
doug: There's not a rush; it would be good to understand overall requirements before adopting this feature
<Gerhard> Adoption is key, so would support. But not if it will mean backwards compatibility/issues with not having a set of these options available. A bit unclear of the implications of 'making the API clear'.
smcgruer_[EST]: I think it's ok to leave the pull request open for short term. But Chrome still needs to make a decision to ship.
smcgruer_[EST]: This is a niche feature IMO; we could unship it.
<Gerhard> +1
Gerhard: I am ok to adopt if we can unship the feature.
<rbyers> With my blink API owner hat on, +1 to likely being able to remove in the future.
Propose: Adopt the opt-out feature into SPC v1 with understanding we might undo this based on future UX improvements
<cferro> +1
<Anne> +1
<Sue> +1
<JeanLuc> +1
IJ: Defer to chairs
Gerhard: smcgruer_[EST] and Rouslan have done good work; there's a client that needs this feature; if they are open to review this; I suggest we go with this
praveena: +1 to Gerhard; I think including the feature will get us more real-world experience
SO RESOLVED
Gustavo: +1
smcgruer_[EST]: For the UX topic, we'll start internal chats and welcome input.
ACTION: Gerhard to gather some input on UX flow needs
Gerhard: Mockups would help!
<rbyers> Thank you all. We always much prefer to ship things that have landed in the official spec, and I really appreciate the urgency for supporting real-world adoption.
Removing user activation requirement in SPC
Proposal to remove user activation requirement
smcgruer_[EST]: We've heard from multiple partners that requiring user activation to trigger SPC is a significant problem. Both Stripe and Adyen are in situations where they don't get a user activation (e.g,. after a redirect)
… the user hasn't clicked anything when they arrive on the PSP to authenticate.
… so we reviewed WHY we had included user activation
… the main reason was that user activation is an important defense when an API can be spammy (e.g., popup windows)
… or if the API can be subversive (e.g., full screen API to quietly fool the user)
… in the case of SPC, we asked where is spamminess and where is subversion?
… after internal discussions we reached conclusion that the one concern was "click-jacking"
… right before the user clicks SPC would be swapped in ... so we propose a simple defense of a short delay.
… our plan would be to introduce an origin trial for this and see if flows improve
… there are security implications and we welcome additional input
<Gerhard> +1 for this.
Proposal is to remove user activation requirement
<Gerhard> Less clicks are better, and SPC shows the real transaction and that's followed with WebAuthn as well.
<Gerhard> So a third forced click seems unneeded.
<Gerhard> And we have in-field feedback for this.
Ian: Time frame for adopting this one?
<cferro> +1 to Gerhard's comments
<JeanLuc> +1
smcgruer_[EST]: Let's say half way through Q1
smcgruer_[EST]: Tell us if important to you
Jean-Luc: I saw the delay to resist click-jacking.
JeanLuc: In EMVCo 3DS there is a timeout; how would the "cool down" period be defined; don't want to interfere with 3DS timeout
smcgruer_[EST]: The initial recommendation was 2-3 seconds. I think it could be .5 seconds or 1 second.
… do those numbers sound scary?
Ian: What is order of magnitude in 3DS?
JeanLuc: Just want to be sure we don't exceed 3DS timeout
smcgruer_[EST]: I think the user won't have time to make a decision before the timeout has completed.
rbyers: The point of this feature is to reduce friction. If we add a timeout that slows user's down; that's a problem. But if the user is reading the dialog, we should not have any problem at all with this additional delay.
… it's a problem if the user is not reading the dialog anyway.
Gerhard: Is there a difference between transaction dialog in 1p or 3p context?
… is there anything that could be factored into this delay consideration?
smcgruer_[EST]: I don't think so. One consideration is a slightly different is cross-origin iframe (and the permissions policy helps)
Gerhard: Another flow we are thinking about is OAuth flow where you are in same domain but redirect to a different site then back
Gerhard: Timing delays are fairly common in banking flows; I'm comfortable with the delay as mitigation strategy
Pull request to remove user-identifiable information from canMakePayment
https://
smcgruer_[EST]: This is a follow-on from TPAC discussion regarding making payment handlers more consistent with privacy sandbox
… we want to avoid using them to recreate 3p cookies
… the proposal here is to reduce what information is shared through canMakePayment()
Ian: Are you thinking about this a payment handlers being able to access 1p context (like FedCM)
smcgruer_[EST]: Yes. But note that this change really removes value of canMakePayment, but we don't have people using it much.
… this goes back to payment handlers...how do we create a good experience without destroying user privacy.
Next Meeting
19 January 2023. We will continue discussion of SPC use cases.