- From: Mike Jones via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Feb 2018 02:52:56 +0000
- To: public-webauthn@w3.org
`clientExtensions` and `authenticatorExtensions` are included in `CollectedClientData` so they contribute to the `clientDataHash` input. This cryptographically binds these input values to the request. The request would mean something different with different extension inputs, so it makes sense to do this. Answering @arnar 's history questions, this was part of PR #425 , which @jyasskin thoroughly reviewed at the time. This was part of the fixes to issue @jyasskin 's issue #418 (along with PR #421 ). This was all actually cleanup to earlier PRs to address @jyasskin 's issue #270 (Processing model for extensions is very underdefined). PR #389 did most of the heavy lifting of making the extension model well-defined and useful. (Among other huge defects, there used to be no distinction between the client and authenticator inputs and outputs, even though the client ones are JavaScript and the authenticator ones are CBOR.) Answering @agl 's question about `getClientExtensionResults`, I'd be fine replacing: `AuthenticationExtensionsClientOutputs getClientExtensionResults();` with `[SameObject] readonly attribute AuthenticationExtensionsClientOutputs clientExtensionResults;` in `PublicKeyCredential`, provided a couple of browser experts such as yourself and @jcjones agree. If there's consensus to do this, I'll create a PR (coordinating with @nadalin about the repository being locked). -- GitHub Notification of comment by selfissued Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366131165 using your GitHub account
Received on Friday, 16 February 2018 02:53:01 UTC