-
Notifications
You must be signed in to change notification settings - Fork 172
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
Drop assertion-time attestation. #1997
Conversation
We don't believe that there's a use for it now. The cases that wish to plumb this sort of data back can do so via other means.
Does that imply that device-bound keys in the "supplemental keys" extension cannot be attested? |
No, they certainly can be. This change just reduces the number of places that can have attestations at assertion time from three to two. |
Big 👍 for this change. Attestation should be stored at creation time and this simplifies the spec. for DBKs creation time can overlap with assertion time of the main credential so it's still during "creation". |
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 to me.
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.
Heh, I spotted this looking strange in the HTML diff:
This was added in PR #1818, and apparently Bikeshed now started pulling in {{AuthenticatorAssertionResponse/attestationObject}}
as an external ref from the spec database since the member definition no longer exists within the document.
I've pushed commit a0cfb6c which fixes this.
SHA: 830e6c0 Reason: push, by agl Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
We don't believe that there's a use for it now. The cases that wish to plumb this sort of data back can do so via other means.
Preview | Diff