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

Re: [webauthn] Can RPs assume that `InvalidStateError` for `create()` means an excludeCredentials match? (#1566)

From: Lucas Garron via GitHub <sysbot+gh@w3.org>
Date: Sat, 20 Feb 2021 23:50:08 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-782767000-1613865008-sysbot+gh@w3.org>
Indeed, therein lies the problem — getting a new browser profile into an appropriate "ambient credential" state.

Your first few paragraphs pretty much describe our current goals.

> If there is no ambient credential, you'd better not asking webauthn authentication (trusted device) in a first place.

> 2\. You can determine whether the user has already registered the platform authenticatior with that device by asking additional webauthn authentication prompt (if there is any registered platform authenticator to that user).
>     If the webauthn authentication is successful, you might create ambient credential for this browser (and device).

Unless I'm misunderstanding, these two are exactly at odds. If we follow step 2 as written, then we *are* asking the user for authentication at a time when there is no ambient credential. We can try to dress it up a friendly UI, but there is no way to control the browser UI for this, which is designed for authentication.

As mentioned before, we'd like to use heuristics to reduce how often this happens, by e.g. skipping straight to your step 3 if we don't think the user has an registered authenticator with the same platform scope (e.g. Windows Hello in any browser/Chrome on macOS/Safari on macOS/Safari on iOS). But our heuristics might be wrong, hence our desire to tell if we guessed wrong because of an existing registration.

-- 
GitHub Notification of comment by lgarron
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1566#issuecomment-782767000 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 20 February 2021 23:50:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 20 February 2021 23:50:12 UTC