-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "conditional mediation" #155
Conversation
See also [WebAuthn Conditional/Hinted UI](https://docs.google.com/document/d/11hWpUPAnblPtkn1f7AIQW0ujoiu_BAKzlMVhZKQPiW8/).
Thanks for including a link to the explainer, that's really helpful. The approach seems reasonable, but it seems like something we should run through the TAG before we'd ship it in Chromium. Would you mind filing a review request? Are other vendors on board with the approach/extra enum value? |
see also w3c/webappsec-credential-management#155 and [Explainer: WebAuthn Conditional/Hinted UI](https://docs.google.com/document/d/11hWpUPAnblPtkn1f7AIQW0ujoiu_BAKzlMVhZKQPiW8/)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few thoughts that came up after more thinking.
(also, did you mean to update the html? seems like a bunch of unrelated changes but if the file is autogenerated maybe it doesn't matter?)
Yeah, I think editors are expected to re-gen the html file at the time of pushing changes to the .bs source file up to the repo here, and I probably didn't do it properly. |
see also w3c/webappsec-credential-management#155 and [Explainer: WebAuthn Conditional/Hinted UI](https://docs.google.com/document/d/11hWpUPAnblPtkn1f7AIQW0ujoiu_BAKzlMVhZKQPiW8/)
* Fix some links * Discover availability by calling a method on each Credential interface object to discriminate between credential types * Instruct the browser to avoid revealing credential availability when using conditional UI on error.
I think it was brought by an earlier merge commit. Should be fine if we squash and rebase this into main later.
535006d
to
9dc6bc8
Compare
@equalsJeffH please take a look, I've addressed the comments (and merged here for ease of maintenance) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nsatragno, this is really close. On detailed review I wonder about whether declaring isConditionalMediationAvailable()
as static
is what we want, and then a few modest editorial suggestions/fixes.
index.bs
Outdated
If no credentials are discovered, the user agent MAY prompt the user to take action in a way | ||
that depends on the type of credential (e.g. to insert a device containing credentials). | ||
Either way, the `get()` method MUST NOT return immediately with `null` to avoid revealing | ||
the lack of applicable credentials to the website. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm nervous about having normative requirements in this section. They need to be reflected in the algorithm below regardless, and having them here too introduces the possibility for them to get out of sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀
I think it's fine since the whole not returning empty-handed is critical to Conditional UI anyway. Either way I changed "return immediately" by "resolve immediately".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point about the MUST NOT. Where does the "MAY prompt" happen? It seems like it'd fit just before the call to "ask the user to choose a Credential, but that doesn't call back to the particular credential types in the list.
This might be a pre-existing difference between the spec and implementations, in which case feel free to defer it to a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the "MAY prompt" happen?
I'm not sure I understand this.
It seems like it'd fit just before the call to "ask the user to choose a Credential,
We could definitely add a note there for credential types other than PublicKeyCredential
.
that doesn't call back to the particular credential types in the list.
WebAuthn loosely specifies its own credential chooser on [[PublicKeyCredential/DiscoverFromExternalSource]]
, and there's a bunch of conditional mediation logic I'm adding there. The implementation matches the spec in a non obvious way: only one credential type is supported at a time, so CredMan's "ask the user to choose a Credential" does not actually prompt the user ("PublicKeyCredential" is always selected as the default) and the webauthn "picker" is shown instead (and the user being prompted to interact with their authenticator satisfies the mediation requests).
I think the way this PR deals with choosing credentials (and the spec before this PR) is correct, or at least good enough. Hopefully that makes sense?
index.bs
Outdated
If no credentials are discovered, the user agent MAY prompt the user to take action in a way | ||
that depends on the type of credential (e.g. to insert a device containing credentials). | ||
Either way, the `get()` method MUST NOT return immediately with `null` to avoid revealing | ||
the lack of applicable credentials to the website. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point about the MUST NOT. Where does the "MAY prompt" happen? It seems like it'd fit just before the call to "ask the user to choose a Credential, but that doesn't call back to the particular credential types in the list.
This might be a pre-existing difference between the spec and implementations, in which case feel free to defer it to a separate PR.
Co-authored-by: Jeffrey Yasskin <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good once you've fixed the build. (This spec ran into whatwg/dom#1027 which renamed the 'aborted flag'.)
nvm I filed pr #176 for this |
8fa9b22
to
5d07770
Compare
This needs a merge-from-main in order to pick up the changes from PR #176 (now merged), which will fix the failing build (the w3c spec-prod machinery stipulates a "die on warning" and so will not build correctly unless all the references and such are properly resolving) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, ready for reviews :)
Thanks @nsatragno !
SHA: b273b4a Reason: push, by @nsatragno Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
see also w3c/webappsec-credential-management#155 and [Explainer: WebAuthn Conditional/Hinted UI](https://docs.google.com/document/d/11hWpUPAnblPtkn1f7AIQW0ujoiu_BAKzlMVhZKQPiW8/)
This PR adds the Credential Management-layer underpinnings necessary for credential types to effect a "Conditional UI" with WebAuthn being the driving use case, as explained in Explainer: WebAuthn Conditional/Hinted UI.
The related WebAuthn issues and PRs are:
Preview | Diff