- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Feb 2018 19:48:53 +0000
- To: public-webauthn@w3.org
@selfissued noted:
> clientExtensions and authenticatorExtensions are included in CollectedClientData so they contribute to the clientDataHash input. This cryptographically binds these input values to the request
@emlun replied (and @agl has been asking):
> Who is the binding for?
Originally, in a hand-wavy fashion, the binding is (ostensibly) for the RP to be able to verify that the authenticator received what was sent and the returned data (back up through "the stack") is as expected. From the original [W3C FIDO Submission Signature Format spec](https://www.w3.org/Submission/2015/SUBM-fido-signature-format-20151120/#overview):
> FIDO 2.0 signatures are bound to various contextual data. These data are observed, and added at different levels of the stack as a signature request passes from the server to the authenticator. In verifying a signature, the server checks these bindings against expected values
So I'll venture that assuring that protecting against the "origin context ... manipulat[ing] the request" is/was at least an implicit goal.
It is good to have fresh security-conscious eyes on the spec and noticing that we are lacking some clothing (thanks:)
> If a compromised origin context is something that we expect to defend against, there are a [lot of fields](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions) in a creation request that are not echoed and so not protected.
agreed, though might necessity of "echoing" of input options fields be assessed on a field-by-field basis?
> the client's outputs can still be manipulated by the origin context
yeah, I'm not sure how one might guard against that.
> The instructions say only that the RP should check that the echoed extensions are a subset...
See issue #804 (thx @emlun)
> Since the CollectedClientData is JSON serialised, that means that all extensions have to be JSON—i.e. no ArrayBuffers, WebCrypto objects etc. (Unless we also define a Javascript to JSON mapping for these types.)
do you actually mean to say "WebIDL to Javascript" mapping?
Our understanding (from browser spec folk, e.g., @jyasskin) is that this is addressed by implicit [conversion](https://heycam.github.io/webidl/#es-type-mapping).
@selfissued [wrote](https://github.com/w3c/webauthn/issues/803#issuecomment-366131165):
> Answering @agl 's question about `getClientExtensionResults`, I'd be fine replacing:
`AuthenticationExtensionsClientOutputs getClientExtensionResults();`
with
`[SameObject] readonly attribute AuthenticationExtensionsClientOutputs clientExtensionResults;`
in `PublicKeyCredential`...
That seems nominally fine by me.
@agl [had originally noted (amongst a bunch of items)](https://github.com/w3c/webauthn/issues/803#issue-297305269):
> On the way back out, step 18.3 of [these instructions](https://w3c.github.io/webauthn/#discover-from-external-source) says that [[clientExtensionsResults]] is an “ArrayBuffer … containing the bytes of assertionCreationData.clientExtensionResults”. But the latter is a [AuthenticationExtensionsClientOutputs](https://w3c.github.io/webauthn/#dictdef-authenticationextensionsclientoutputs) so how is that turned into a bytestring?
If we change to the `clientExtensionResults` attribute, then it seems step 18.3 of [these instructions](https://w3c.github.io/webauthn/#discover-from-external-source) would become, nominally:
>clientExtensionResults
A new `AuthenticationExtensionsClientOutputs` object associated with |global| whose members are copies of the members of `assertionCreationData.clientExtensionResults`.
..though I'm unsure of the "members are copies of" portion.
--
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366340258 using your GitHub account
Received on Friday, 16 February 2018 19:48:59 UTC