wrt webauthn stack layer boundaries (was: External amd embedded authenticators (was RE: Notes from WebAuthn Review)

[ My reading of AdamP's specific questions below is that they are more
regarding how the webauthn layers are divided up, rather than about
external and embedded authnrs (tho they do raise quesitons regarding the
latter two things), so I'm forking this yet again. I'll reply to Vijay's
comments under his original subject. ]

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
>> 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
>not authenticator behavior.

Well, that is a bit of a misunderstanding -- yes, the spec could be more
clear about this. 

Essentially, when we crafted the webauthn API, the boundary between the
layers "below" the two webauthn api methods -- makeCredential() and
getAssertion() -- are deliberately "fuzzy". I.e., "the platforms" (user
agents (UA) and OSes + authnrs) reserve the right to craft the "webauthn
stack" below the latter webauthn api methods in whatever fashion makes
sense to them.  Of course, for interoperability purposes the signed
objects must be generated and procesed per spec, and the overall
behavior/results of the makeCredential() and getAssertion() methods must
be per spec, but they can be implemented in various fashions ("under the

See also:  <https://w3c.github.io/webauthn/#conformance> 1st parag, and
<https://w3c.github.io/webauthn/#authenticator-model> 1st parag.

>This step seems to imply that upon a successful
>makeCredential() call, the user agent stored some tuple like {
>authenticator identifier, credential id, credential type, RP ID }.

not necessarily "the user agent".  Note that the spec step cited above
explicitly says "..optionally execute a platform-specific procedure.."  --
platform-specific implies UA+OS+Authnrs (IIUC), and where the lines are
drawn is largely up to the implementors of those things.

So when we speak of an "..authnr generates and stores..", we are to some
degree hand-waving in terms of which entity in the webauthn stack is
implementing the functionality.

Regardless, if "the platform" supports the optional step you originally
cited, it will, in conjunction with the authenticator, "do its best" to
determine if any of the given credential.ids already exist on the authnr.

>Now, in getAssertion() the user agent is going to do something
>like iterate through its list of available authenticators and see if it
>has a
>matching { credential id, credential type } that matches the ids / types
>the whitelist.

"the platform" is going to do the above, where "the platform" =

>If my understanding is correct, there should be a corresponding step in
>algorithm of Section 3.1.1, where makeCredential() stores the credential
>associated with the authenticator.

I do not feel this would be appropriate given how the spec is fashioned,
as described above.



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