Use credential record abstraction in devicePubKey extension #1812
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
emlun
added
type:editorial
process:meta-pr
Base automatically changed from
jeffh-fix-1658-device-bound-key-extension
to
main
October 7, 2022 20:05
emlun
force-pushed
the
dpk-credential-record
branch
from
36ee3ed
to
25291de
Compare
emlun
removed
the
process:meta-pr
agl
approved these changes
Dec 2, 2022
timcappalli
reviewed
Dec 21, 2022
index.bs
Outdated
| ##### Registration (`create()`) ##### {#sctn-device-publickey-extension-verification-create} | ||
|
|
||
| If the `devicePubKey` extension was included on a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>this step</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. | ||
| If the `devicePubKey` extension was included on a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>step 18</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. |
There was a problem hiding this comment.
If the devicePubKey extension was included on a navigator.credentials.create() call
The RP may request a DPK via the extension, but the authenticator may not provide one. Is this referring to the request or response?
Do we need a statement in the processing logic for when the authenticator doesn't provide it back, or would that just be generic for all extensions?
There was a problem hiding this comment.
(and now in hindsight, I realize these comments are likely more appropriate for the DPK PR itself, not yours. let me know if I should move them)
There was a problem hiding this comment.
I think that's covered by the last part:
[=[RP]=] policy may specify whether a response without a
devicePubKeyis acceptable.
But evidently it could still use some clarification, then. :) How about this?
Suggested change
| If the `devicePubKey` extension was included on a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>step 18</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. | |
| If the `devicePubKey` extension was requested in a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>step 18</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. |
Or perhaps even:
Suggested change
| If the `devicePubKey` extension was included on a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>step 18</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. | |
| If the [=[RP]=] requested the `devicePubKey` extension in a {{CredentialsContainer/create()|navigator.credentials.create()}} call, then the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>step 18</a> of [[#sctn-registering-a-new-credential]] using these variables established therein: |credential|, |clientExtensionResults|, |authData|, and |hash|. [=[RP]=] policy may specify whether a response without a `devicePubKey` is acceptable. |
There was a problem hiding this comment.
@timcappalli Any thoughts on the above suggestions?
There was a problem hiding this comment.
@emlun the latter (If the RP requested) I think is the most clear.
There was a problem hiding this comment.
Thanks @timcappalli!
I also edited the last phrase to
[...] without a
devicePubKeyextension output is acceptable.
I'll assume that's an acceptable edit too.
github-actions bot
added a commit
that referenced
this pull request
Jan 13, 2023
SHA: d3270c5 Reason: push, by emlun Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This applies the new abstraction from #1773 and #1807 to the
devicePubKeyextension, which can substantially streamline the RP processing steps for the new extension.Preview | Diff