Re: use cases

inline below..

On 5/26/16, 6:29 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).

wrt the latter point -- and has been mentioned by another responders -- if
the laptop implements CTAP in the authnr role, then it would not
necessarily be "useless" for the latter use case.


>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). 

Is not the salient distinction here whether the authnr is a "passwordless"
first-factor authnr or whether it is only a second-factor authnr, rather
than  the distinction being whether the authnr is
external/portable/roaming or embedded/bound ?  It seems the latter
physical attachment characteristics are orthogonal to an authnr's
first-factor or second-factor capabilities, no?


>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.

We could add a parameter to makeCredential() and getAssertion() that
contains an `unsigned int`, say, and define one of the bits to be a
"UseSecondFactor" flag, and another to be a "UseFirstFactor" flag. If both
are set, use either, if one or the other are set, use as directed, if
neither are set, catch fire or something (just kidding). and we could
regard the remaining bits as reserved in case we determine there's other
additional notions we need to express when invoking those methods.

This relies on the platform (UA+OS) to have some means for understaning
authnrs' capabilities, at least whether an authnr is first- or
second-factor. 

thoughts?

=JeffH

Received on Thursday, 9 June 2016 22:00:33 UTC