Re: [webauthn] credential ID returned by authenticatorGetAssertion() is optional if allowList has exactly one member

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

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, 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 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 ([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.

GitHub Notification of comment by domenic
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 20 June 2017 19:54:04 UTC