fixup algs contd 3#498
Conversation
equalsJeffH
left a comment
There was a problem hiding this comment.
I have a couple items below that I'd like to alter in this and solicit feedback. Please see the below comments. thx.
| configuration knowledge of the appropriate transport to use with |authenticator| in making its | ||
| selection. | ||
|
|
||
| Then, using |transport|, invoke [=in parallel=] the [=authenticatorGetAssertion=] operation on |
There was a problem hiding this comment.
I am thinking that the "in parallel" clauses in these substeps (of current step 16) ought to be replaced by a single "in parallel" clause on Step 16 itself (new line 822, above).
If others agree, will do that in a subsequent commit.
There was a problem hiding this comment.
hold on there pardner, see @domenic's thoughts in this comment on issue #472: #472 (comment)
There was a problem hiding this comment.
I think it is fine as it is right now. Don't see the benefit of replacing the three in parallels with a single one.
Not that concrete implementations could still use a single in parallel invocation of authenticatorGet line-of-code and only prepare the parameters in the current is-empty/is-not-empty branches (as that is semantically equivalent). Even code generators might automatically perform this transformation.
There was a problem hiding this comment.
actually, as suggested in #472 (comment) (mentioned above), we will remove those [=in parallel=] invocations because we are already on a background thread given how we are invoked from https://w3c.github.io/webappsec-credential-management/#algorithm-request
| @@ -855,28 +883,29 @@ When this method is invoked, the user agent MUST execute the following algorithm | |||
|
|
|||
| <dl class="switch"> | |||
There was a problem hiding this comment.
new line 881 above should be a substep of the step above it at new line 878. If others agree, will make that change in a subsequent commit.
There was a problem hiding this comment.
I'm thinking this is a "go" given @domenic's thoughts in this comment on issue #472: #472 (comment) and other examples of how algs are written, e.g. in credman.
|
See @domenic's comments in issue #472. summary: this alg needs more work to get the thread-handling and JS-object construction stuff correct. |
|
Based on domenic's comment, there are still some works on how to address exception and creation of exception object. @equalsJeffH do you plan to do that in a separate PR? Or do you prefer to address them in this one altogether? |
|
@AngeloKai asked
thx, nominally I'd prefer to do it all in the context of this PR, unless there's some really good reasons to merge this as-is. |
| 1. [=In parallel=], invoke the [=authenticatorMakeCredential=] operation on |authenticator| with | ||
| |clientDataHash|, <code>|options|.{{MakeCredentialOptions/rp}}</code>, <code>|options|.{{MakeCredentialOptions/user}}</code>, | ||
| |normalizedParameters|, |excludeCredentialDescriptorList|, and |authenticatorExtensions| as parameters. | ||
| 1. [=set/Append=] |authenticator| to |issuedRequests|. |
There was a problem hiding this comment.
I would typically do this step before invoking the authenticatorMakeCredential in parallel in order to avoid race conditions, in which the authenticatorMakeCredential already returns and hence would invoke the "authenticator indicates success" code without having this task in the list.
There was a problem hiding this comment.
I think it's a readability improvement, but I believe it doesn't affect the correctness. Specifically, "If any authenticator indicates success," is checked later within the main thread, so there's no way that authenticatorMakeCredential returning early could run those steps before the authenticator is added to issuedRequests.
There was a problem hiding this comment.
plus, this entire alg is now running "in parallel" and the [=in parallel=] on old line 678 is now gone. So I'm not sure there's anything to change here.
| authenticator is being asked to exercise any credential it may possess that is bound to the [=[RP]=]. | ||
| </dl> | ||
|
|
||
| 1. [=set/Append=] |authenticator| to |issuedRequests|. |
There was a problem hiding this comment.
see my previous command on reversing the order to appending to issuedRequests and invoking the request in parallel (and potential race conditions).
rlin1
left a comment
There was a problem hiding this comment.
I have added two comments about the order of statements.
Other than that: LGTM.
|
I think we found another limitation of the algorithm specified in section 4.1.4: However, if the authenticator has no UI (e.g. like PQI My Lockey 360°), the authenticator would need platform support for the credentialID selection. It would be great to add such support (e.g. by (1) letting the platform know whether or not the authenticator has a UI and (2) by letting the platform retrieve a list of credentialIDs from the authenticator - after user verification). If we feel that this is too much of a heavy lifting at this stage, we should at least document the supported scenarios and the limitations. At this stage it is not very obvious for a reader. |
|
new, improved "return an algorithm" technique -- employed in the #createCredential section -- is ready to review. rendered html: http://kingsmountain.com/doc/diff/diff-webauthn-index-jeffh-fixup-algs-contd-3-7b272f1--from--index-master-ee174c2.html rendered text-only: http://kingsmountain.com/doc/diff/diff-webauthn-index-jeffh-fixup-algs-contd-3-7b272f1--from--index-master-ee174c2.html.pdf |
|
|
||
| : <code><dfn>extensionOutputsMap</dfn></code> | ||
| :: whose value is an [=ordered map=] with [=map/keys=] of type [=extension identifier=] | ||
| and [=map/values=] of type [=client extension output=]. <code>[=extensionOutputsMap=]</code>'s |
There was a problem hiding this comment.
Note that "client extension output" isn't a type. I believe the old wording was pretty close to fine, with "AuthenticationExtensions" replaced by "ordered map". The biggest problem there is that it's only implied that the map keeps the order provided by clientDataJSON.clientExtensions, but I wouldn't bother fixing that in this PR.
There was a problem hiding this comment.
good catch, IIUC. Tho, this parag will now different because we merged PR #633 -- am updating this parag accordingly
There was a problem hiding this comment.
well, actually ended up using the "old wording" you referred to. Tho this raises issue #657.
| the [=client extension outputs=], for each [=client extension=] in | ||
| <code>{{AuthenticatorResponse/clientDataJSON}}.clientExtensions</code>. | ||
|
|
||
| 1. Let |constructCredentialAlg| be an algorithm that takes a [=environment settings object/global object=] |
There was a problem hiding this comment.
takes a [=global object=], which should resolve to https://html.spec.whatwg.org/multipage/webappapis.html#global-object.
| : If any |authenticator| indicates success, | ||
| :: 1. [=set/Remove=] |authenticator| from |issuedRequests|. | ||
|
|
||
| 1. Let |credentialCreationData| be a [=struct=] whose [=items=] are: |
There was a problem hiding this comment.
This is fine, but I believe you'd also be fine just defining three variables with the values you've put into items here, and doing that would be a bit shorter.
There was a problem hiding this comment.
Ok, tho will leave this as-is for now since it is OK and we want to get this merged.
|
|
||
| 1. Return |constructCredentialAlg| and terminate this algorithm. | ||
|
|
||
| Issue: Do we need to replicitly return both |constructCredentialAlg| and |credentialCreationData| here? |
There was a problem hiding this comment.
I believe that it's sufficient to return only constructCredentialAlg, on the theory that algorithm variables are captured by any subroutines that use them and only garbage-collected when all capturing routines are done. The main thing you have to guarantee is that no variable is used and modified in parallel, which we have to do by inspection whether or not you explicitly return the set of captured variables.
There was a problem hiding this comment.
ok, thanks, I'll remove that "Issue:"
|
per 18-Oct webauthn call, I've addressed @jyasskin's latest comments. This is ready to merge AFAIK. Since I did make some modest changes in response to the latter comments, perhaps someone(s) oughta review prior to merge? Making similar changes to the #getAssertion section is yet to do in a separate soon-to-follow PR. Regarding Rolf's oldish review that is requesting changes, It seems to me that there is nothing to do in response to it, unless I am misunderstanding things. I ping'd him on-list a few weeks ago about this, but have not heard back. So are we ok to "dismiss" is review in order to merge this? thanks! |
jcjones
left a comment
There was a problem hiding this comment.
I think this is ready to go. I'll go re-review Rolf's comments from earlier though and make a recommendation.
Since Rolf previously said "LGTM" other than the in-parallel concern, which has been handled, I think he would be in agreement to proceed.
#665) * actually improve #254, and fix #661 * DiscoFrmExtSource(options) -> (origin, options) * make [[DiscoFrmExtSource]]'s exposition match [[Create]]'s * deal with yet another fix #254 straggler in [[Create]] * get rid of |global| in [[DiscoFrmExtSource]] * remove 'in parallel' and 'global' stuff from #discover-from-external-source alg * work on #discover-from-external-source alg to improve #254 * finish (one hopes) work on #discover-from-external-source alg to fix #254 * minor editorial * repair #createCredential intro parag, improves issue #671 * complete fix #671
this builds on PRs #371 and #495. it resolves these issues:
improves #254 (#getAssertion section will be updated in a separate PR and issue #254 will be fixed at that time)
fix #466
fix #472
fix #536
fix #559
Preview | Diff