Suggestion to enable Frictionless Flows

[Goosth]

Introduction

We’ve heard a lot about ‘frictionless authentication’ at TPAC 2020 regarding SPC. It’s considered an essential requirement for merchant adoption in certain markets, due to the historic pain experienced with issuer challenges. It's a key benefit promised for 3D Secure 2.

This post is an suggestion on how we could utilize the SPC public-key-credential to payment-card linking mechanism to enable frictionless authentication. The idea is inspired by the Credential API picture in the presentation given at the TPAC WPWG sessions (slide 14, thanks @danyao).

SPC was implemented by adding a new credential type (PaymentCredential) to the Credential Management API. This new PaymentCredential type includes a list of other trusted public-key credentials; which today consist of a set of WebAuthn Keys (called PublicKeyCredential in the Credential Management API).

Proposal

What if we supported an additional type of credential that can be used frictionlessly. Ideally this would also be a public-private keypair, similar to Webautn’s PublicKeyCredential. This credential would have the following attributes:

• a Public-Private keypair, both created in the browser instance and where the private key is never exposed to anything.
• The ability to sign a challenge without requiring user-action.

This attribute would then be able to show a certain browser presence during a transaction.
This functionality actually already exists in WebCrypto API. The object created is called CryptoKey.
In CredentialManagement, we could call this a CryptoKeyCredential. The CredentialManagement API would bring the ability to get user-consent when this is created. And it would then be stored and retrievable in a similar way to other Credentials.

Our PaymentCredential would then be able to link into both PublicKeyCredentials and CryptoKeyCredentials (via existingCredential).

Enabling this flow.

So, if this was in place and an issuer wanted to enable frictionless flows it would just need to do the following:

Enroll

• Create a new CryptoKeyCredential on a trusted browser (getting user consent that they trust this browser)
• Link this new CryptoKeyCredential to a PaymentCredential, potentially also with a set of PublicKeyCredentials that’s also trusted by this user

Checkout

• When the issuer needs to return a list of trusted credentials, they can indicate the option of a frictionless flow (based on risk), by returning CryptoKeyCredentials in the list returned to the merchant.
• When SPC is initiated, it would first check if any frictionless CryptoKeyCredentials returned are present on the browser, and if they are, they could be used as signing proof of the transaction. If none are present it would try the WebAuthnCredentials, and failing that fallback to the fallback URL.

If I understand the SPC API and implementation correctly, this would require virtually no change to the SPC interface. Just the ability to store a new credential type in the browser. And in return, we would be able to offer frictionless SPC consent.

Would be great to explain and explore this further in future WPWG session.

[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