- From: Hodges, Jeff <jeff.hodges@paypal.com>
- Date: Tue, 7 Jun 2016 00:01:47 +0000
- To: "Powers, Adam" <adam@fidoalliance.org>
- CC: W3C Web Authn WG <public-webauthn@w3.org>
[ 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 >>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. 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 hood"). 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 >in >the whitelist. "the platform" is going to do the above, where "the platform" = UA+OS+Authnrs > >If my understanding is correct, there should be a corresponding step in >the >algorithm of Section 3.1.1, where makeCredential() stores the credential >id >associated with the authenticator. I do not feel this would be appropriate given how the spec is fashioned, as described above. HTH, =JeffH
Received on Tuesday, 7 June 2016 00:02:19 UTC