- From: GitHub <noreply@github.com>
- Date: Tue, 03 May 2016 14:42:48 -0700
- To: public-webauthn@w3.org
- Message-ID: <57291b5838d01_528a3f8b8a2df2bc6283f@hookshot-fe1-cp1-prd.iad.github.net.mail>
Branch: refs/heads/master Home: https://github.com/w3c/webauthn Commit: 634c269257db45919bec3cc4c7dd0dc40a492e0a https://github.com/w3c/webauthn/commit/634c269257db45919bec3cc4c7dd0dc40a492e0a Author: Vijay Bharadwaj <vijaybh@users.noreply.github.com> Date: 2016-05-03 (Tue, 03 May 2016) Changed paths: M index.src.html Log Message: ----------- Represent binary data as ArrayBuffers instead of base64-encoded DOMStrings (#77) * Represent binary data as ArrayBuffers instead of base64-encoded DOMStrings 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 from packed and TPM attestation formats Remove base64 encoding from the rawData fields and return them directly as ArrayBuffers. * Clarify Android attestation procedure
Received on Tuesday, 3 May 2016 21:43:17 UTC