Re: External amd embedded authenticators and use cases (was RE: Notes from WebAuthn Review)

note that Vijay's comments below are relevant to the "use cases" thread..

  https://lists.w3.org/Archives/Public/public-webauthn/2016May/0281.html

.. (which itself is about external (aka 'portable' aka 'roaming') and
embedded (aka 'bound') authenticators)...

AdamP replied..
> =JeffH had written..
>> AdamP had commented on webauthn spec..
>>> fpwd webauthn spec sez..
>>>>
>>>> * If whitelist is defined and non-empty, <<<< optionally
>>>>   execute a platform-specific procedure to determine which of these
>>>>   credentials can possibly be present on this
>>>>   authenticator.
>>>
>>> Implies cred id was stored in makeCred?
>>> Maybe some hint in makeCred?
>>>
>> yes, the authnr generates and stores a tuple of { private key, cred id,
>> cred type, RP ID } -- this is stated in "The authenticatorMakeCredential
>> operation" <https://w3c.github.io/webauthn/#op-make-cred>, though it
>> could perhaps be stated more rigorously.
>
> My understanding is that this section is talking about user agent
>behavior,
> not authenticator behavior.


On 6/4/16, 2:14 PM, "Vijay Bharadwaj" <vijaybh@microsoft.com> replied to
AdamP:
>
>This seems to intersect with something Dirk brought up in
><https://lists.w3.org/Archives/Public/public-webauthn/2016May/0281.html>

agreed that it seems to intersect.

> It does seem like youšve hit another case where external and embedded
> authenticators behave differently. For an embedded authenticator, it
> would be reasonable to assume that the user agent can reliably know a
> mapping between credential ID and authenticator. But for external
> authenticators (which can roam) this may not be the case since the
> credential may have been created somewhere else, the authenticator
> might not be plugged in at the moment, etc.

I think "may not" is appropriate in the latter sentence, because the other
side of the coin is also true: the Platform (UA+OS(+authnrs)) /may have/
the desired information, one way or another, and "how" is
platform-specific.


> Do you think this indicates we should support (e.g. by adding an
> optional parameter) the ability to request an embedded vs. external
> authenticator in makeCredential?

well, i actually think the embedded vs. external/roaming distinction is
not what Dirk was actually getting at, but rather the distiction of
whether the authnr is first-factor (ie, passwordless) or second-factor
(password/pin still required). Note that a roaming authnr can also be a
first-factor (passwordless) authnr, eg a USB fingerprint authnr.

That said, yes, adding the ability for the RP to stipulate whether a
first-factor or second-factor authnr is employed at registration time may
be needed in order to more easily craft user experiences that make sense.
we probably need to craft and examine use cases (as Dirk has begun) in
order to make an informed decision.


> If so, should there also be a way
> for an RP to detect the presence of embedded authenticators?

possibly.

> (You
> canšt detect the presence of external authenticators because they may
> just not be plugged in right now,

The Platform could report on existence of roaming/external authnrs that
are known to the plaform, eg have been paired.

> or not tapped to the NFC reader,
> etc. ­ at best, you can detect if the client supports the notion of
> external authenticators

in terms of NFC-attached authnrs, yes, the platform could indicate whether
it supports them.


HTH,



=JeffH

Received on Tuesday, 7 June 2016 00:02:21 UTC