credential ID returned by authenticatorGetAssertion() is optional if allowList has exactly one member

[equalsJeffH]

The authenticatorGetAssertion operation says:

On successful completion, the authenticator returns to the user agent:
* The identifier of the credential used to generate the signature.
* The authenticator data used to generate the signature.
* The assertion signature.

However, the CTAP spec says in 4.2 authenticatorGetAssertion:

On success, the authenticator must return the following structure in its response:

Member name  Data type   Required?  Definition
credential   Credential  Optional   Credential whose private key was used to 
                                     generate the assertion. May be
                                     omitted if the whitelist has exactly 
                                     one Credential.
[...]

..which would seem to be an optimization for CTAP where it does not have to return as many bytes (in what may be a common case).

Update WebAuthn to reflect this?

[equalsJeffH]

Hm, if the authnr's returning of Credential ID is optional in the case where the webauthn client invokes authenticatorGetAssertion() with exactly one credential descriptor in allowCredentials[], then in this case the client needs to maintain state -- the Cred ID -- until the call to authenticatorGetAssertion() returns and then set {{PublicKeyCredential/[[identifier]]}} to the saved value, yes? And that saved value needs to be in some global-to-the-window object (or roughly equivalent) I'm guessing?

Is this a case of "snapshotting" ?

I took a stab at doing this in 31a8f85

/cc @bzbarsky @jyasskin @jcjones

[bzbarsky]

Please re-cc me if there's a specific question for me.

[equalsJeffH]

@bzbarsky yes, the above questions are for you if you have time to consider them (the other guys are out-of-pocket for a while). thanks.

[bzbarsky]

I guess I just don't understand the questions then. They seem to be about details of authn that I'm not familiar with, not about the general platform integration aspects....

[equalsJeffH]

The questions are about how to save state (a particular value) from before the invocation of an async operation, until the async operation returns, and then combine the saved value with the async op's returned values. abstracted out, it's like this:

if a given sequence |A| has exactly one value, then let |S| be a new ArrayBuffer, created using |global|'s %ArrayBuffer%, and containing the bytes of |A|[0].
[..invoke async op.....op returns..]
Create a new ArrayBuffer, using global|'s %ArrayBuffer%. If |S| exists, set the value of the new ArrayBuffer to be the bytes of |S|. Otherwise, set the value of the new ArrayBuffer to be the bytes of the fooBar returned from the op. [...]

Is the above more or less correctly specified, or not? thanks for your help.

[bzbarsky]

So basically you want to pass some sort of data through the async op? I'm not sure what the best current spec language for that is. @domenic ?

[domenic]

I'm having a hard time understanding the above, and I tried reading 31a8f85, but without context it's not very intelligible to me. At first glance those sentences seem OK-ish, although generally you want to be more explicit about going in-parallel and then posting a task to get back to the main thread. But it seems like you're taking care to not create or manipulate main-thread objects during your off-main-thread async work, so that's good at least.

[equalsJeffH]

So basically you want to pass some sort of data through the async op?

Well, not "through" the async op. Rather, want to remember something "globally" (on the "main thread" ?) "outside" the async op.

So, thanks guys -- I take that as meaning that at a first-order approximation the new language is OK enough for now.

wrt..

generally you want to be more explicit about going in-parallel and then posting a task to get back to the main thread.

might you be able to point to a spec that does the above, that we might learn from?

thanks again.

[domenic]

https://www.w3.org/2001/tag/doc/promises-guide#queue-tasks

[equalsJeffH]

Ok thanks. Is not "posting a task to get back to the main thread" part of inherent Promise machinery? In the case of the alg discussed here, it is called-into by navigator.credentials.get() wherein the Promise resolution/rejection is handled.

[domenic]

If the only thing you do back on the main thread is resolve/reject a promise with a pre-existing value (usually undefined), then we have defined them to post a task. (Although that is somewhat controversial/buggy; see w3ctag/promises-guide#52.)

But if you do anything else back on the main thread, such as creating an object, you need to post a task to do that.

Now that I've been linked to https://w3c.github.io/webauthn/#getAssertion, I see a few problems:

• "Let global be the PublicKeyCredential's interface object's environment settings object’s global object." should probably just be "Let global be the PublicKeyCredential's relevant global object". Sorry this stuff is so convoluted.
• Step 17 states a task source but it's going in parallel; it's not posting any tasks. Instead step 18 "If any authenticator indicates success" should be posting the task (and stating the task source) since it needs to go back to the main thread to create the object.
• The algorithm is theoretically synchronous as stated at the top, but it goes in parallel. But it appears we're already in parallel (i.e. on the background thread) when it's called, by https://w3c.github.io/webappsec-credential-management/#abstract-opdef-request-a-credential step 5.9? It seems like the separation here is not working that well.

I think I would advise:

• The algorithm stays synchronous
• Anywhere it says "in parallel" gets removed. It's doing all its work on the background thread already.
• It never returns actual JS objects or messes with actual JS globals. Instead it returns the necessary data to create one. (Perhaps as an Infra struct.)
  • This also needs to be done for the exceptions, actually.
• The "request a credential" operation, after synchronously retrieving the error code or data necessary to create a credential, posts a task (going "back to the main thread") to actually do the object/exception creation and resolve/reject the promise.

You can see some pretty similar spec-code in WebAssembly/design#1093 (preview). That PR's processing/success/failure steps are probably not quite necessary in your case, so no need to emulate that somewhat inside-out structure, but hopefully it conveys the way in which you weave between threads.

Hope this helps... I do feel every time I end up in this repository I see you tackling with some of the hardest issues in spec-writing, so my heart goes out to you.

[equalsJeffH]

Thanks for the review & guidance @domenic !

@domenic noted in irc #whatwg that when he says "post a task", he means "[=queue a task=]"

@domenic wrote:

• The algorithm stays synchronous
• Anywhere it says "in parallel" gets removed. It's doing all its work on the background thread already.

Ok.

It never returns actual JS objects or messes with actual JS globals. Instead it returns the necessary data to create one. (Perhaps as an Infra struct.)

Ok, will look to WebAssembly/design#1093 (preview) for guidance.

• The "request a credential" operation,

ah, you are referring to webappsec-credential-management/#abstract-opdef-request-a-credential here it seems.

after synchronously retrieving the error code or data necessary to create a credential, [queues] a task (going "back to the main thread") to actually do the object/exception creation and resolve/reject the promise.

ok, though IIUC, webappsec-credential-management/#abstract-opdef-request-a-credential does not itself presently "queue a task...to actually do the object/exception creation and resolve/reject the promise", yes?

I am thinking that all the "object/exception creation and resolve/reject the promise" functionality could be specified in the webauthn spec in a fashion similar to WebAssembly PR #1093's approach.

WDYT?

/cc @mikewest

[equalsJeffH]

see also issue #254 "There is no "current settings object" in algorithm steps that are executing in parallel" for additional context wrt what's at issue here. see especially #254 (comment)