Suggestion to enable Frictionless Flows

[Goosth]

Suggestion to enable Frictionless Flows

[danyao]

Thanks @Goosth for bringing up new use cases. :-)

What kind of user experience are you envisioning with the "frictionless" flow? Would the signing be completely invisible from the user? If so, I think there may be a privacy issue: any RP can use the presence of the private key to track users.

Also how would this flow handle the Dynamic Linking use case? If user is not seeing any visible UI, who is acting as the trusted component to facilitate the user's confirmation of the transaction details?

These are the reasons why the user interaction with the browser UI is crucial in the current SPC proposal.

[ianbjacobs]

@danyao,

If I've understood, there are two user gestures involved:

1. Enrollment: The user consents to the creation of the CryptoKeyCredential.
2. Transaction: The CryptoKeyCredential is only made available to the issuer after the user has selected an instrument to make the payment.

That's not a careful privacy analysis, but I want to see if @Goosth agrees that those user gestures are expected.

Ian

[danyao]

I think Transaction/checkout (i.e. the flow that exercises the CrytoKeyCredential) is the key flow for analyze for privacy. From @Goosth's original description, it's not clear if a user interaction is involved in checkout. I assumed that true "frictionless" implies no user interaction. It'll be good to clarify if this is not the case.

[Goosth]

We have to find the right balance of friction. We're all in agreement that the payment must be confirmed by the user before the cryptogram will be returned. It cannot be done without user action on that page. So there will be at least one action; this proposal will prevent us from having to add to that.

The Credential management API allows us to save a username and password and refill this automatically when a user goes back to that primary site. See example here. So this paradigm is already in place, and I have to assume that this was done in a way that is considered save & free of tracking. The user must be part of the journey to store and retrieve that data. The Customer goes to this primary site (e.g. bank.com) and chooses to be remembered by taking a user action.

So, to @ianbjacobs 's point, there are 2 events:

1. Enrollment (on bank site): The user will consent (take action on the site) to be remembered. I'd suggest we follow the same paradigm as for password storage in Credential Management.
2. Payment (on merchant site):

• The User will have to click a 'Checkout' button on the merchant website. So the SPC should always be invoked based on user action.
• If no checkout button is pressed (the SPC is just activated without user action) the SPC 'confirmation' page can appear to confirm the transaction details. Alternatively it can just fail.

So in both cases user needs to act on something to retrieve the information (only 1 action however). It cannot be done silently.

[danyao]

So, to @ianbjacobs 's point, there are 2 events:

1. Enrollment (on bank site): The user will consent (take action on the site) to be remembered. I'd suggest we follow the same paradigm as for password storage in Credential Management.
2. Payment (on merchant site):

• The User will have to click a 'Checkout' button on the merchant website. So the SPC should always be invoked based on user action.

According to Chrome's privacy design principle, invoking SPC should always trigger a browser UI that displays to the user the transaction details. User must interacts with this browser UI to proceed. I'm not sure if this is what you originally meant by "1 click" because I'm counting 2 clicks here. But if this is what you envision, then I agree the privacy surface here is identical to Credential Management API.

For example, in the Credential Management API demo you referenced, there are two actions when a returning user signs in:

1. User clicks on "Sign In" button rendered inside the web content of the Relying Party => this triggers the browser UI
2. User clicks on "Sign in" again in the browser UI

The privacy problem comes from not involving the browser UI. We don't consider a user interaction with a DOM element a sufficiently strong signal of the user's intent to initiate payment authentication because the web content cannot be trusted. A malicious website can easily use a misleading label on the button such as "Click here to get a free coupon".

• If no checkout button is pressed (the SPC is just activated without user action) the SPC 'confirmation' page can appear to confirm the transaction details. Alternatively it can just fail.

So in both cases user needs to act on something to retrieve the information (only 1 action however). It cannot be done silently.

[Goosth]

Thanks for the clarification here @danyao.

So are we then saying that something like the following will happen

• The end user will make a final field selection (eg. shipping details) and hit 'Continue'
• The merchant will invoke SRC to confirm the details with the consumer. this will open an SRC page with transaction details and a Confirmation/Verify button.
• Once pressed the cryptogram will be generated and returned.

The solution will therefore still require a merchant confirmation step, but no additional/visual authentication using a biometric or Device PIN. This will be a great replacement to remove frustrating SMS OTP flows (fully compliant for all transactions outside of Europe). And it would support a very convenient low-friction flow for situations where full SCA is not required in Europe.

This could be a good compromise to enable a 'frictionless' flow if desired by the Issuer.

[ianbjacobs]

Based on further conversation, adding a remark here: if there are any options in the user experience, this raises the question of prioritization of concerns. My initial recommendation would be:

• The user must be able to configure the consent experience they want, including "please always do biometric auth."
• The relying party should be able to convey a preference to the user agent (but that can be overridden by the user).
• The merchant should be able to convey a preference to the relying party.

[Goosth]

I would add to this that if the Relying party indicates it's preference for 2FA (Biometric/PIN + possession), the user or merchant should not be able to waive that. They are the relying party after all.

[ianbjacobs]

@Goosth, interesting point. "More security wins" could be an interesting principle. (I need to think more about it. "Security" may be the wrong word here, although I hope it's the right word.)

[ianbjacobs]

Labeled after-v1 based on 3 March 2022 WG discussion https://www.w3.org/2022/03/03-wpwg-minutes