Conditionally-shown Transaction UX and WebAuthn

[stephenmcgruer]

Conditionally-shown Transaction UX and WebAuthn

Hey folks; I wanted to write up this issue not to suggest any change, but to raise
awareness of a tricky part of SPC and to allow people to digest and perhaps discuss.

This issue meanders along the grey area between purist API and hard reality, so I will
mention Chrome specifically in parts. Generally speaking one can substitute the word
'Chrome' with 'any browser concretely implementing SPC'.

Preamble - the need for conditionally-shown UX

In the current design, SPC asks the caller (e.g. the merchant) to provide a list of
credentials it has received from the Relying Party (e.g. the bank). The reason it is a list
is that neither the Relying Party or the caller are allowed to know what device a given
credential is for, to protect user privacy. As such, the credentials one has for this user
(who has identified themselves via providing payment instrument information, e.g. a
credit card number) may or may not match the current device.

The desired behavior for SPC, as I see it, is that the user should only see the subsequent
Transaction UX (from the browser), if there is a possibility that they could successfully
complete SPC - i.e. if one of the credentials in the list matches this device. This means
that the Transaction UX is a conditionally-shown UX. When the conditional is false (i.e.
no credentials match), the user should not see the Transaction UX*.

Thus, I hope this establishes the need for conditionally-shown UX. If you disagree here,
stop and leave a comment now because the rest assumes this :D.

* For privacy, in Chrome the user will likely see another UX instead, that informs
them their device isn't registered and the site will likely try another method for
authentication. This prevents an attack in which you can probe for credential
existence by relying on whether an API like SPC immediately fails or not.

Conditionally-shown UX: Current approach in Chrome

To enable this conditionally-shown UX today, Chrome does something quite hacky
for SPC; it caches created SPC credentials locally (and in a per-user storage), so that
it can later match them when an SPC call is made. The reason this is necessary is
that WebAuthn does not (in general) allow the browser to discover the existence or lack
thereof of a credential without the user interacting with their authenticator.

The browser-local storage works in a world where only Chrome is implementing SPC, and
where users only use one profile per browser (which is generally true), but falls apart quickly
in a multi-browser world. The failure mode is quite straightforward; if a credential is registered
in another browser, Chrome will fail to recognize it as matching this device and will fail an SPC
call that tries to use it. This then has knock-on implications, as it is likely the caller (e.g.
merchant) will try to register the device again, which may disturb the existing credential.

The WebAuthn solution: Conditional UI

Unsurprisingly, WebAuthn has faced the same problem for some login usecases, and they have
already come up with a solution! The catch is that the solution doesn't exist yet. (It's likely to
come into existence some time in 2022.)

WebAuthn's solution is called Conditional UI, and it basically adds the ability for the browser
to query for credential existence without requiring a user interaction.

So, perfect, right? We can use the hacky local-storage for now, and then when Conditional UI
comes along we can switch over to that and everyone is happy.

Alas, not quite so easy...

The catch - Discoverable Credentials

In WebAuthn there are multiple dimensions, or properties, in which credentials can differ.
One of these is the concept of whether the credential is 'discoverable' or not (historically
called 'resident keys', a term that has thankfully been mostly deprecated). In WebAuthn,
a Discoverable Credential exists on the authenticator device in some way that a client
(the browser) could say 'fetch all the credentials for rp.com, and let the user pick one of
them to use in an authentication ceremony' - that is, the Relying Party doesn't need to
provide the credential(s) to use.

It is my understanding that the WebAuthn world is roughly moving in the direction where all
credentials may be discoverable, but that's just my amateur knowledge and may be inaccurate.
What is definitely true is that some OSes (currently Windows) only create Discoverable
Credentials, and that Conditional UI intends to require Discoverable Credentials (source).

Thus, we come to our corollary: if SPC is to rely on Conditional UI one day,
SPC must only work for Discoverable Credentials.

Requiring Discoverable Credentials - the consequences

Requiring Discoverable Credentials is not inherently problematic, but it does come
with its own set of challenges:

• Discoverable Credentials are unique for a given (rp, user_id) pair. Combined with the
  current caching described above, this is the case where a valid credential could be
  incorrectly overwritten because the browser-local cache didn't know about it. (Note:
  This is already a problem on Windows, where all credentials are discoverable.)
• Relying Parties must know to create Discoverable Credentials if they want to use SPC.
• Existing SPC credentials are non-Discoverable on non-Windows OSes (as the Origin
  Trial version of SPC set residentKey="discouraged"). Credentials created during the
  Chrome Origin Trials would not work with SPC later.
• Android does not currently support Discoverable Credentials. Given that they will be
  required for Conditional UI I suspect this support will come, but in the meantime SPC
  wouldn't be available on Android.

I believe many of these challenges can be overcome via clear guidelines for RPs and
callers of SPC as to how they should manage their credentials.

Alternatives

There are some alternatives we could consider, instead of betting on Conditional UI
and accepting Discoverable Credentials as a requirement.

• Always show the Transaction UX. Much simpler, much more confusing for users.
• Make Conditional UI work for any credential, as long as the credential is passed in.
  Naively I believe this is technically possible, but I have not heard any appetite from
  WebAuthn folks to enable it - there seems a strong belief that Discoverable Credentials
  are better.

[adrianhopebailie]

+1 for requiring Discoverable Credentials and depending on Conditional UI.
In the long term this is the best solution.

Is it possible to experiment with the API shape and do some more trials while we wait for these features to roll out more widely?

To address the consequences listed:

Discoverable Credentials are unique for a given (rp, user_id) pair. Combined with the current caching described above, this is the case where a valid credential could be incorrectly overwritten because the browser-local cache didn't know about it (Note: This is already a problem on Windows, where all credentials are discoverable.)

Am I correct in my understanding that the browser cache is not required if SPC only uses discoverable credentials? Is this actually a non-issue in a world where SPC uses Conditional UI and Discoverable Credentials because there is no longer a browser cache?

Relying Parties must know to create Discoverable Credentials if they want to use SPC.

Seems like a reasonable requirement

Existing SPC credentials are non-Discoverable on non-Windows OSes (as the Origin Trial version of SPC set residentKey="discouraged"). Credentials created during the Chrome Origin Trials would not work with SPC later.

We shouldn't compromise the design based on the origin trials

Android does not currently support Discoverable Credentials. Given that they will be required for Conditional UI I suspect this support will come, but in the meantime SPC wouldn't be available on Android.

Long term this seems like it will solve itself.

[stephenmcgruer]

Am I correct in my understanding that the browser cache is not required if SPC only uses discoverable credentials? Is this actually a non-issue in a world where SPC uses Conditional UI and Discoverable Credentials because there is no longer a browser cache?

Correct, assuming you substitute 'Conditional UI' for 'discoverable credentials' in your first sentence. If/once Conditional UI exists on a given platform, no browser cache (or alternative mechanism) is required.

[stephenmcgruer]

I think this write-up has served its purpose, and is now even slightly out of date, so closing.

The main outcomes of this were:

• The steps to determine if a credential is SPC-enabled
• The steps to silently determine if a credential is available for the current device
• The ongoing discussion in Cross origin authentication without iframes (accommodating SPC in WebAuthn) webauthn#1667