W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2018

Re: [webauthn] AttestationResponse vs AssertionResponse

From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Mar 2018 10:18:10 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-376836106-1522232289-sysbot+gh@w3.org>
I don't think the attestation interface was _converted_ to CBOR, instead it's just that the `attestationObject` and the unwrapped `authenticatorData` are the raw results returned from the authenticator. The argument "servers need to understand CBOR anyway" was against duplicating information (the public key, mainly) from the attestation object in an easier to use format, because the RP will need to parse the binary structures anyway in order to verify the signatures.

Returning them raw also meant that the _client_ didn't have to parse the CBOR. That premise may be out of date now, though, as clients are now expected to blind attestations (i.e., modify the `attestationObject`) unless the RP asks for direct attestation. But you're right that the only things that _need_ to be passed through untouched are the `authenticatorData`, `clientDataJSON` and signature, so it would be functionally equivalent to transform the `attestationObject` to a JavaScript object structure.

Just off the top of my head, though: One argument against doing that is that new attestation statement formats can't be used if the client doesn't know how to transform them. If that means the raw `attestationObject` needs to be passed along as well as a fallback, then we're back at duplicating information, which I think would be more confusing than slightly different response formats.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/854#issuecomment-376836106 using your GitHub account
Received on Wednesday, 28 March 2018 10:18:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:48 UTC