- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Jun 2020 13:04:17 +0000
- To: public-webauthn@w3.org
> There are also the subsections where it's not clear yet imo: > > * [5.2.1](https://w3c.github.io/webauthn/#iface-authenticatorattestationresponse), here it even says `The exact JSON serialization MUST be preserved, as the hash of the serialized client data has been computed over it.` which doesn't make sense if only the hash is transmitted anyway > > * [5.2.2](https://w3c.github.io/webauthn/#iface-authenticatorassertionresponse), same > > > Wouldn't it be useful to rename this field to `clientDataJSONHash`or something similar in a future draft? These instances are correct. Although only the hash is sent to the authenticator, the RP needs the original, un-hashed `clientDataJSON` in order to verify the content that was signed over. I would not rename this field. > While looking through the spec I just noticed another anomaly with `clientDataJSON`. In [5.1.3](https://w3c.github.io/webauthn/#sctn-createCredential) and [5.1.4](https://w3c.github.io/webauthn/#sctn-getAssertion) during the creation of `credentialCreationData` and `assertionCreationData` it uses `clientDataJSON.clientExtensions` but `clientExtensions` are never a part of `clientDataJSON` as far as I can tell. Thanks, good catch! Those should probably be `|options|.{{PublicKeyCredential{Creation,Request}Options/extensions}}` instead. > Is it ok if I use issues for questions with the specification like this or should I use the mailing list? Issues here are welcome. Questions about specific implementations may be redirected to the mail list or other forums, though. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1443#issuecomment-647506026 using your GitHub account
Received on Monday, 22 June 2020 13:04:18 UTC