W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2021

[webauthn] Support a "create/get/replace" credential re-association operation (#1568)

From: Lucas Garron via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Feb 2021 03:26:16 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-804170647-1612841175-sysbot+gh@w3.org>
lgarron has just created a new issue for https://github.com/w3c/webauthn:

== Support a "create/get/replace" credential re-association operation ==
## Proposal

I would like to propose the addition of a way for an RP to indicate that the user has certain existing registrations, and ask the browser to:

- Prompt the user to create a new credential, if possible.
- Prompt the user to authenticate an existing credential otherwise.

In essence "create or get", where "or" has similar meaning to many programming languages (take the second branch if the first was unsuccessful).

This could either be implemented as an option to `create`, or as a new API call in addition to `create` and `get`.


## Motivation

I originally asked about this #1533 and I felt my concern was dismissed quickly because this was an intentional omission of the spec. However, after a lot of work on GitHub's WebAuthn implementation, and several dozen emails with browser authors, it seems that there is still a fundamental issue with authenticators that are shared across multiple browsers:

- It is impossible for the RP to tell if the user has an existing registration or not.
  - If the RP always prompts the user to create a *new* credential in a fresh browser session, the *expected* user experience is that the user encounters an error.
  - If the RP offers a "get" option, then they are making their registration flow needlessly complicated for first-time registrants. This also puts responsibility on the user to remember on which sites/devices/browsers they have signed in before, which seems counter to goals of folks working on WebAuthn. It also requires sites to put in extra engineering effort.

Note that:
- Some browsers create discoverable credentials even if the RP does not ask for it.
  - In particular, this means that they may create credentials in a way that invalidates previous registrations for the same RP, even if the RP did not ask for this. (Safari and Windows Hello both do this at the moment.)
- RPs may not want to use discoverable credential auth at the time they first start creating discoverable credentials. They may set `residentKey: "preferred"` but initially only use the credentials as if they were server-side.
- As far as I know, there are no browsers that currently allow users to manage registrations. All the registrations remain forever.
- It is currently hard to tell if a `create` call failed due to an existing registration: https://github.com/w3c/webauthn/issues/1566

This puts a wrench in certain hacky workarounds, like using a different user handle for each browser session (which not only seems contrary to the intention of the user handle, but can result in a ballooning set of redundant registrations if discoverable credentials are created).

It can also wreak havoc with sites that have existing registrations for security keys, and want them to keep working while adding support for passwordless flows.


To me, it seems that the benefits of a "create or get" operation like this outweigh the complexity or security implications. It would allow RPs to:

- Check for `isUserVerifyingPlatformAuthenticatorAvailable()`
- If true, show a simple prompt saying "would you like to use [your device's built-in authenticator](https://github.com/w3c/webauthn/issues/1563) to sign in to this site?"

To me, it seems that this would support the [priority of constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) better than only supporting `create` or `get` in the spec.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1568 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 03:26:18 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:42 UTC