W3C home > Mailing lists > Public > public-webauthn@w3.org > September 2016

RE: [webauthn] Move `allowList` from optional to default on `getAssertion`

From: Vijay Bharadwaj <vijaybh@microsoft.com>
Date: Wed, 28 Sep 2016 15:53:02 +0000
To: Richard Barnes <rbarnes@mozilla.com>
CC: "public-webauthn@w3.org" <public-webauthn@w3.org>
Message-ID: <2ecb95cc12b74c939778c83a3a45b717@microsoft.com>
Requiring the allowList means that the RP must know which credential IDs are relevant in this particular interaction (you would not expect Google to send all registered credential IDs in its database for example). To narrow that scope, you need some hint saying which user’s credential IDs you are looking for. At the same time, you don’t want an unauthenticated client to probe for specific account IDs or users either. So you must have some basic idea of who the user is (or some other way to narrow the list of credential IDs, but similar arguments would apply to any other filter).

From: Richard Barnes [mailto:rbarnes@mozilla.com]
Sent: Wednesday, September 28, 2016 8:37 AM
To: Vijay Bharadwaj via GitHub <sysbot+gh@w3.org>
Cc: public-webauthn@w3.org
Subject: Re: [webauthn] Move `allowList` from optional to default on `getAssertion`

I don't see how you arrive at the equivalence -- it's only enforcing that makeCredential happened before getAssertion.  Says nothing at all about whether there's any other authentication.

Sent from my iPhone.  Please excuse brevity.

On Sep 28, 2016, at 00:49, Vijay Bharadwaj via GitHub <sysbot+gh@w3.org<mailto:sysbot+gh@w3.org>> wrote:
Requiring allowList is equivalent to saying that getAssertion can only
provide supplementary authentication, i.e. give you more assurance
about a user whose identity you already sort-of-know. However I
believe we do want to support scenarios where the user can
authenticate with their WebAuthn authenticator and nothing else.

GitHub Notification of comment by vijaybh
Please view or discuss this issue at

using your GitHub account
Received on Wednesday, 28 September 2016 15:53:46 UTC

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