- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Feb 2018 19:19:43 +0000
- To: public-webauthn@w3.org
I don't think clarifying the existing processing moves the spec to a coherent place. I think the major decision is whether a compromised origin context is something we wish to defend against. If so: 1. The echoed extensions need to be included verbatim so that the RP can check that the origin context didn't manipulate them at all. That suggests to me that they should be specified in the first place as a JSON string to simply the comparison and to make it clear that they're limited to JSON values. 1. The client extensions outputs also need to be included to prevent the origin context from manipulating them. (See the case of the [biometricPerfBounds](https://w3c.github.io/webauthn/#sctn-authenticator-biometric-criteria-extension) example cited above.) 1. Other values from the credential request need to be included because, if this is an attack that we're defending against, then we should do it uniformly. If we believe that a compromised origin context is not something that we defend against (which I think is a reasonable position too) then the echoed extensions should be dropped. In both cases I believe the echoed authenticator inputs should be dropped. It appears that we can simply the `getClientExtensionResults` function into a mere field again if J. C. agrees. That's relatively minor, however. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366332885 using your GitHub account
Received on Friday, 16 February 2018 19:19:46 UTC