Make AuthenticatorAttestationResponseJSON.clientDataJSON a DOMString or USVString about webauthn

[MasterKale]

Is the reason AuthenticatorAttestationResponseJSON.clientDataJSON defined that way for consistency alone? Specifically that all ArrayBuffers are converted to that?

Yes, the intention was to use consistent encoding of ArrayBuffer values to something that would survive transmission to the server. As clientDataJSON is bytes it made sense to treat it like any other ArrayBuffer, even though as is outlined in the spec it's handled as a UTF-8 string during response verification.

[zacknewman]

Fair enough.

[emlun]

Adding to what @MasterKale said - critically, the encoding of clientDataJSON MUST remain byte-for-byte identical in transmission from authenticator to server so that the signature over it remains valid. Intermediate parties should not be led to believe that they can safely parse and re-serialize the JSON, because any change to it would break the signature even if the re-serialized JSON is semantically equivalent. Therefore clientDataJSON is defined as a byte array rather than a DOMString, to emphasize that intermediate parties should consider it as opaque. These are essentially the same reasons as why JWS also serializes everything as base64-encoded byte arrays even though many of the components are JSON data.

[zacknewman]

Adding to what @MasterKale said - critically, the encoding of clientDataJSON MUST remain byte-for-byte identical in transmission from authenticator to server so that the signature over it remains valid. Intermediate parties should not be led to believe that they can safely parse and re-serialize the JSON, because any change to it would break the signature even if the re-serialized JSON is semantically equivalent. Therefore clientDataJSON is defined as a byte array rather than a DOMString, to emphasize that intermediate parties should consider it as opaque. These are essentially the same reasons as why JWS also serializes everything as base64-encoded byte arrays even though many of the components are JSON data.

clientDataJSON is not the only item that must remain identical though. For example RP ID must also remain identical since a SHA-256 hash of it is matched with rpIdHash in authData; yet PublicKeyCredentialRpEntity.id is modeled as a DOMString and not ArrayBuffer. I find it more likely RP ID gets altered in transit since an RP ID only needs to be a valid domain string. For example, www.EXample.com very likely will be altered into www.example.com when sent from the server to authenticator which will cause the registration to fail. Perhaps that is an issue with how RP ID is defined; but even if the definition were improved to require the RP ID to be the result of the domain-to-ascii algorithm, it would still be essential it does not get altered and thus be modeled as an ArrayBuffer.