[webauthn] Creation of ScopedCredentialInfo in makeCredential should probably be more explicit

bzbarsky has just created a new issue for 
https://github.com/w3c/webauthn:

== Creation of ScopedCredentialInfo in makeCredential should probably 
be more explicit ==
In 
https://w3c.github.io/webauthn/#dom-webauthentication-makecredential 
step 11 the spec says:

> Create a new ScopedCredentialInfo object named value and populate 
its fields with the values returned from the authenticator as well as 
the clientDataJSON computed earlier.

But ScopedCredentialInfo doesn't have a useful place to put a 
clientDataJSON.  Presumably that should go into the clientData member 
of the attestation member of the ScopedCredentialInfo?  That needs to 
be made clear.

In general, I think it would be good to define the interface between 
this code and 
https://w3c.github.io/webauthn/#transport-authenticatormakecredential 
more clearly in terms of which part of the return set of things go 
where on the object that gets created.  For example, 
https://w3c.github.io/webauthn/#transport-authenticatormakecredential 
says that it needs to return

> The fields of the attestation structure WebAuthnAttestation, 
including information about the attestation format used.

but it has no way to return the clientDataJSON, because it doesn't 
have it...

Also, is authenticatorMakeCredential  expected to create the 
ArrayBuffer for the new ScopedCredentials's id member?  Or is that the
 job of makeCredential?  Presumably the latter, right?  Which global 
is that ArrayBuffer created in?   Presumably this creation step needs 
to happen off a task queued back to some task queue, since it's going 
to need to create ES objects, so can't happen on random background 
threads.  Which task queue?  That matters in terms of event ordering 
with other things.  Which globals are used for the various other 
objects involved in this ScopedCredentialInfo?  

Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/277 using your GitHub account

Received on Friday, 4 November 2016 21:20:18 UTC