Summary:
FIDO U2F's specification says that when the wrong security key responds to a
signature, or when an already-registered key exists, that the UA should return
error code 4, DEVICE_INELIGIBLE. We used to do that, but adjusted some things
for WebAuthn and now we don't. This changes the soft token to return that at
the appropriate times, and updates the expectations of U2F.cpp that it should
use InvalidStateError as the signal to reutrn DEVICE_INELIGIBLE.
Also, note that WebAuthn's specification says that if any authenticator returns
"InvalidStateError" that it should be propagated, as it indicates that the
authenticator obtained user consent and failed to complete its job [1].
This change to the Soft Token affects the WebAuthn tests, but in a good way.
Reading the WebAuthn spec, we should not be returning NotAllowedError when there
is consent from the user via the token (which the softtoken always deliveres).
As such, this adjusts the affected WebAuthn tests, and adds a couple useful
checks to test_webauthn_get_assertion.html for future purposes.
[1] https://w3c.github.io/webauthn/#createCredential section 5.1.3 "Create a new
credential", Step 20, Note 2: "If any authenticator returns an error status
equivalent to "InvalidStateError"..."
Test Plan: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2fc930f7fc8eea69b1ebc96748fe95e150a92a4
Reviewers: ttaubert
Bug #: 1460767
Differential Revision: https://phabricator.services.mozilla.com/D1269
--HG--
extra : transplant_source : M%5B%93%81%29%7E%B2%E8%24%05%A6%96%8BUN%C9%FB%3E%B3h
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
Summary:
This patch restricts any calls to navigator.credentials.* methods to selected
tabs. Any active WebAuthn request will be aborted when the parent chrome
window loses focus, or the <browser> is backgrounded.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409202
Differential Revision: https://phabricator.services.mozilla.com/D688
--HG--
extra : amend_source : 112378a1ab2e883d7603e8a28ff3f8e944d57b5f
For the "js" crate, disable the "regex" feature to reduce binary size.
For the "u2fhid" crate, it's used only in examples. Make it a dev-dependency
so it won't be part of the Firefox build.
MozReview-Commit-ID: DY9indMqrRw
--HG--
extra : rebase_source : aa66fe1effaeca0ae35ec5dd20b33724eb3fac48
Summary:
Always replace attestation statements with a "none" attestation.
Bug 1430150 will introduce a prompt that asks the user for permission whenever
the RP requests "direct" attestation. Only if the user opts in we will forward
the attestation statement with the token's certificate and signature.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1416056
Differential Revision: https://phabricator.services.mozilla.com/D567
Late-breaking rename pre-CR in Web Authentication [1] renamed a dictionary. It's
not an interop issue, really, which must be why it was let through. This is a
WebIDL and Web Platform Tests-only issue. (The WPT updates are happening at
Github [2])
[1] https://github.com/w3c/webauthn/pull/779/files
[2] https://github.com/w3c/web-platform-tests/pull/9237
MozReview-Commit-ID: KEIlqIYbzKp
--HG--
extra : rebase_source : 4204ea62a41f374a6731a9367552af122d354145
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
The Web Authentication CollectedClientData is missing the type field, which
is just a simple string. (The editor's draft also removes hashAlgorithm, but
let's not get ahead of ourselves...)
Add in that simple string. This was found at interop testing.
MozReview-Commit-ID: DlawLyHTYhB
--HG--
extra : rebase_source : 6cdd8e14161dc4aea5bfd1baf60c7384219ba951
The WebAuthn spec lets RPs ask to specifically get direct attestation certificates
during credential creation using the "Attestation Conveyance Preference" [1].
This change adds that field into the WebIDL and ignores it for now. This is
pre-work to Bug #1430150 which will make this useful (which in turn requires
Bug #1416056's support for anonymizing those attestation certificates).
[1] https://www.w3.org/TR/webauthn/#attestation-convey
MozReview-Commit-ID: 763vaAMv48z
--HG--
extra : rebase_source : 7fb7c64a0ee3167032485378af6074a7366295a4
Summary:
Add support for PublicKeyCredentialRequestOptions.userVerification. For now
this basically means that we'll abort the operation with NotAllowed, as we
don't support user verification yet.
Pass PublicKeyCredentialDescriptor.transports through to the token manager
implementations. The softoken will ignore those and pretend to support all
transports defined by the spec. The USB HID token will check for the "usb"
transport and either ignore credentials accordingly, or abort the operation.
Note: The `UserVerificationRequirement` in WebIDL is defined at https://w3c.github.io/webauthn/#assertion-options
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406467
Differential Revision: https://phabricator.services.mozilla.com/D338
--HG--
extra : amend_source : 314cadb3bc40bbbee2a414bc5f13caed55f9d720
webauthn says[1] that public keys are encoded as COSE keys. I find the COSE
RFC quite circuitous in many respects and so any reviews should check whether
they agree with my understanding of what should be in a COSE key.
The webauthn spec says that the key:
“MUST contain the "alg" parameter and MUST NOT contain
any other optional parameters.”
I don't believe that any of the parameters included are optional but, again, I
don't think the RFC is completely clear.
[1] https://www.w3.org/TR/webauthn/#sec-attested-credential-data
MozReview-Commit-ID: 2023mW3yVWU
--HG--
extra : rebase_source : 21d84d67f19d1885b73473a4d77d15f6c4cd80c2
webauthn says[1] that public keys are encoded as COSE keys. I find the COSE
RFC quite circuitous in many respects and so any reviews should check whether
they agree with my understanding of what should be in a COSE key.
The webauthn spec says that the key:
“MUST contain the "alg" parameter and MUST NOT contain
any other optional parameters.”
I don't believe that any of the parameters included are optional but, again, I
don't think the RFC is completely clear.
[1] https://www.w3.org/TR/webauthn/#sec-attested-credential-data
MozReview-Commit-ID: 2023mW3yVWU
--HG--
extra : rebase_source : 2cc9df48ed1ba9f940f57a3148ec881c1b0630df
Summary: We can probably abstract more stuff in the future, but this seems like a good start.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1396907
Differential Revision: https://phabricator.services.mozilla.com/D323
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
