webauthn
webauthn copied to clipboard
w3c
device public key extension
The resolves #1658 by defining the devicePubKey extension et al. It is admittedly rough and will need further work, thus am casting it as a "draft" PR.
update 4-Mar-2022: @ve7jtb has submitted issue https://github.com/w3c/webauthn/issues/1701 --- this PR needs to be updated to address it.
update 19-Mar-2022: commit f0fe8f2 is a rough start at adding an authenticator-generated nonce to attObjForDevicePublicKey: fixes #1701
update 23-Mar-2022: there's now commits beyond f0fe8f2 attempting to further refine the RP usage and extension output verification procedures. Though, see also issue #1711 and https://github.com/w3c/webauthn/pull/1663#issuecomment-1077868106: issue #1711 really needs to be addressed as a part of the devicePubKey effort.
together, 55e64c9 and 41ffcbf embody (a) polishing/expansion of the intro prose, and (b) very rough, first draft verification procedures (which will undoubtedly receive further polishing (suggestions welcome!)).
on the 9-Feb-2022 call:
-
it was suggested that the "RP operations" sections should explicitly link to the device public key verification procedures. commit 23ea3ef does this.
Note that the reverse linkage was already true: the device public key verification procedures explicitly link to the "extension output processing" steps in the "RP operations" sections.
-
We should note, perhaps in the devicePubKey extension definition section, that an authenticator-cum-platform may have UX to allow for users to delete or rotate DPKs.
on 23-Feb-2022 call: @ve7jtb has submitted issue #1701 --- this PR needs to be updated to address that.
Subsequently, in commit 17f3aa2, I've explicitly noted issue #1701 in the spec and made clarifications/updates to the "Relying Party Usage" section in an effort to make it more accurately reflect the significance of the signatures returned by the devicePubKey extension.
on 19-Mar-2022 I added commit f0fe8f2 as a rough start at adding an authenticator-generated nonce to attObjForDevicePublicKey intended to fix issue #1701. It undoubtedly needs further revision and polish.
cc: @agl @emlun @ve7jtb @akshayku
On 23-Mar-2022 f145234 and b8d8567 further refining the RP usage and extension output verification procedures.
Though, see also issue #1711: In the RP operations sections, the attestation signature (in registration op) and the user credential signature (in authentication op) are not verified until near the end of the operation, thus they call for extension processing before knowing whether the overall operation is valid. (this is a security issue)
Since the devicePubKey extension validation (and usage) processing calls for the RP to be updating information stored in user accounts, issue #1711 really needs to be addressed as a part of the devicePubKey effort.
(We know @equalsJeffH was a member of the group at the time he made the PR. If/when it's ready for merging, we can deal with the IPR bot.)
Sorry, I meant to submit 88be1a6dd6701059482c7bbbb1961ea08f84863d as a meta-PR but accidentally pushed it directly into the PR. Let me know if I should roll it back.
Sorry, I meant to submit https://github.com/w3c/webauthn/commit/88be1a6dd6701059482c7bbbb1961ea08f84863d as a meta-PR but accidentally pushed it directly into the PR. Let me know if I should roll it back.
Nope, that's totally fine, thank you!
(Hoping to do another pass today ahead of tomorrow's meeting.)
From the call of 2022-10-05: address https://github.com/w3c/webauthn/pull/1663/files#r790893167 and then work with Wendy to get this landed.
Noting that @equalsJeffH made his contributions while a Member participant in the WG, and thus with IPR commitments under the W3C Patent Policy, I'm dismissing the IPR bot with "non-substantive" mark. Thanks @agl!