RE: use cases

Sure, it's a spectrum but I would carve out "no user authentication" as its
own category rather than a point on that spectrum.

Dirk said it best:
"a simple U2F USB token shouldn't be allowed to log me into my RP account
(without any other factor), since it's not able to identify the user"

I suspect that disallowing login using a capacitive touch USB token (or
similar) will be a common use case. It sounds like we may be considering a
filtering mechanism for authenticators during makeCredential(), and as long
as that can filter on "no user authentication" vs "some user
authentication", I think we should be able to easily enable the login use
case for RPs.

Just to be clear, quantifying "some user authentication" vs "no user
identification" is probably easier and more important than trying to assign
a description to all the points in the spectrum of "strength of
authentication". Also, "some user authentication" vs "no user
authentication" seems to be closer to the heart of the matter than
"embedded" vs "external".

On June 6, 2016 at 12:15:05 AM, Vijay Bharadwaj (vijaybh@microsoft.com)
wrote:

> Aren’t “gesture” and “user identification” (in your terminology) just
> points on the spectrum of strength of user authentication, which extends
> from “trivial” to “super hard”? Why would we presume a priori that an RP
> would require a particular strength of authentication? This seems like a
> job for attestation.
>
>
>
> You make a good point that one device’s embedded authenticator is possibly
> another device’s external authenticator. But from the point of the host
> device itself, this does not matter. For that device, there are credentials
> it is reasonably expected to know about (embedded) and those it might not
> know about (external). This distinction may be useful, see my fork of the
> “Notes from WebAuthn review” thread.
>
>
>
> Thoughts?
>
>
>
> *From:* Adam Powers [mailto:adam@fidoalliance.org]
> *Sent:* Sunday, June 05, 2016 11:25 PM
> *To:* W3C WebAuthn WG <public-webauthn@w3.org>; Dirk Balfanz <
> balfanz@google.com>
> *Subject:* Re: use cases
>
>
>
> I don’t think the differentiator is embedded vs. external; I think it’s
> “gesture” vs “user identification”.
>
>
>
> For the 2FA use case, the requirements are that the device be previously
> enrolled with the RP — regardless of whether it is embedded or external. I
> can imagine scenarios where an embedded authn could be registered for 2FA
> (such as during account creation on that device) and then subsequently used
> from that same device (browser cache cleared; different browser; different
> app; etc.). In this scenario, it doesn’t matter if it’s biometric or human
> gesture, since 2FA would just want a test of human presence and biometrics
> should meet that requirement. If the embedded authenticator isn’t
> registered with the RP and you don’t want to list it as an option, the
> whitelist during getAssertion() might fix that problem (pending other
> design issues).  In my mind, there aren’t any new filtering requirements
> needed for 2FA.
>
>
>
> The biometric login use case couldn’t allow “gesture only” authns, and
> would need to filter out that class of authns during makeCredential().
>
>
>
> I would go further and say that “embedded” doesn’t mean “only locally
> usable”, since most OSes will have some form of local communication (NFC,
> Bluetooth, etc.) potentially enabling an authenticator to be embedded today
> and appear as an external authenticator to another device tomorrow.
> Obviously that would require OS support, but that potentiality further
> diminishes the reason to differentiate between embedded vs. external.
>
>
>
> On May 26, 2016 at 6:31:04 PM, Dirk Balfanz (balfanz@google.com) wrote:
>
> Hi there,
>
>
>
> in Berlin we were talking about how the webauth API supports (at least)
> two use cases:
>
>
>
> - first (or subsequent) logins on a new device with a "portable"
> authenticator (USB token, BLE fob, phone, etc.) being used as a second
> factor.
>
>
>
> - re-authentication on a device that has a built-in authenticator (such as
> fingerprint reader, Windows Hello, etc.)
>
>
>
> It seems to me that some authenticators are useless in one use case, and
> others are useless in the other use case. When calling the API, the RP
> should be able to somehow make sure that they don't end up with an
> authenticator that is unsuitable for the use case that they have in mind.
>
>
>
> Let me elaborate:
>
>
>
> When an RP has a 2-factor product (such as Google's 2-Step Verification),
> it typically means that users that opt into this product *have* to use the
> second factor (authenticator) to log in, whenever they log in. In
> particular, when I log into the RP from a new device for the first time, I
> need to be able to use the authenticator that is already associated with my
> account. In that sense it needs to be "portable" (I need to be able to
> "bring it to" the new device that I'm logging in from for the first time).
> On the other hand, as our experience with FIDO U2F shows, this
> authenticator doesn't need to be particularly advanced - no need for
> biometrics, etc.
>
>
>
> Contrast this with a use case in which a user that is *not* a two-factor
> user with the RP (they could be a 2-factor user, but they don't have to be)
> has logged in to the RP from a new device (using, presumably,
> username+password). Let's also say that this new device has some built-in
> authenticator that can identify the user, such as a fingerprint sensor, or
> a camera with face recognition, etc. It would be nice (and is, indeed, a
> use case that we explicitly want to support with the webauthn API) if the
> RP could tell the user "you don't have to use your password from this
> device anymore, you can log in using your fingerprint/Hello, etc.". This is
> essentially what the current UAF deployments enable.
>
>
>
> Note that the same API is supposed to support both use cases. For example,
> in both use cases, there is a call to getAssertion(). In the first use
> case, it's to verify the second factor (which could be a simple device such
> as a U2F USB token); in the second case it's to sign in the user (through
> some biometric such as fingerprint or face recognition, *without* a
> password). Also note that the two types of authenticators are entirely
> unsuitable for the *other* use case: for example, a simple U2F USB token
> shouldn't be allowed to log me into my RP account (without any other
> factor), since it's not able to identify the user. Likewise, a built-in
> face recognition-based authenticator in a laptop is useless as a
> second-factor authenticator: I can't use it to log into the RP from a new
> device (some device other than the laptop).
>
>
>
> How should we solve this problem? My first inclination would be to let the
> RP specify, during makeCredential(), whether they need a portable
> authenticator (which can be used as a second factor), or whether they need
> a user-identifying authenticator (which can be used to log in the user).
> Note that these are not mutually exclusive - you could imagine a portable
> authenticator with a fingerprint sensor that can be used for both use
> cases. But I'm not entirely sure whether the portable-vs.-identifying is
> really what's getting to the heart of the matter here.
>
>
>
> Any thoughts?
>
>
>
> Dirk.
>
>
>
>