Represent binary data as ArrayBuffers instead of base64-encoded DOMStrings #77
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
…rings Fixes #61. I switched the main API completely from base64-encoded DOMStrings to Buffersource (for input parameters) and ArrayBuffer (for output parameters). The actual signatures are still computed over the same data as before, so signatures computed after this change will be compatible with those computed before, except for being represented differently. I moved the ClientData section into the Authenticator model section since it is not directly used by script authors. This structure still does base64 encoding of the challenge, for two reasons. First, this maintains backward compatibility. Second, it is more natural to represent a binary challenge in JSON as base64 rather than the clunky array notation. I would like to advocate for also changing the rawData in the TPM and packed attestation formats to ArrayBuffers so we can sign directly over the data without base64 encoding. That would seem to simplify processing. However this would break compatibility so I would like to gather opinions from the group before making that change. On the bright side, I do not know of any implementations producing WebAuthn attestation statements in these formats yet.
Remove base64 encoding from the rawData fields and return them directly as ArrayBuffers.
|
Your decision to maintain the Base64-encoding in the LGTM. r=me. |
|
LGTM. |
|
Merging this in now that we have two reviews. |
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.
Fixes #61.
I switched the main API completely from base64-encoded DOMStrings to
Buffersource (for input parameters) and ArrayBuffer (for output
parameters). The actual signatures are still computed over the same data
as before, so signatures computed after this change will be compatible
with those computed before, except for being represented differently.
I moved the ClientData section into the Authenticator model section
since it is not directly used by script authors. This structure still
does base64 encoding of the challenge, for two reasons. First, this
maintains backward compatibility. Second, it is more natural to
represent a binary challenge in JSON as base64 rather than the clunky
array notation.