W3C home > Mailing lists > Public > public-webauthn@w3.org > December 2020

[webauthn] How should website authors "get or create"? (#1533)

From: Lucas Garron via GitHub <sysbot+gh@w3.org>
Date: Fri, 04 Dec 2020 21:54:51 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-757433327-1607118890-sysbot+gh@w3.org>
lgarron has just created a new issue for https://github.com/w3c/webauthn:

== How should website authors "get or create"? ==
Suppose a site is trying to implement "trusted device" functionality, as suggested at https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality.

The first registration is easy:
- Call `isUserVerifyingPlatformAuthenticatorAvailable()`.
- If so, prompt the user to register a trusted device.

Suppose that the user now signs into another browser that shares the same platform authenticator (e.g. using Windows Hell).

Also suppose that the site would like the user to be able to associate the new browser with the existing trusted device, so that they can be managed together. (This allows users to manage and trust actual physical devices like "Alice's Surface Pro", not browser sessions.) In this case, the site would need to either `get` which platform authenticator is associated with the existing device, or `create` a new one if needed. I see two options:

- Ask the user to register a device, and let the user run into a duplicate registration error. Then offer the user to associate the device instead.
- Ask the user "is this a new or an existing trusted device?" and show the corresponding prompt (with a fallback to the other).

Both of these cause "unnecessary" confusion for the user — compare this to the simplicity of authenticator flows for any native mobile app. Is there any way to avoid this, either with the current spec or any likely future changes?

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 December 2020 21:54:53 UTC

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