- From: Arnar Birgisson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 May 2018 17:32:38 +0000
- To: public-webauthn@w3.org
The "second option" works well, as there isn't anything currently in the spec that disallows client processing in an extension to add things to collectedClientData. IMO that would be the right way to implement the kind of an extension described here. The ClientExtensionOutputs is there so that the client still add outputs *after* performing getAssertion with the authenticator. It's true that this doesn't have the same integrity protection, but to compromise the latter you do need to compromise the origin, which is usually not in our attacker model. I see two resolutions: Close this and leave it implicit that extensions may put things in clientData, or add a note in the spec to call that out specifically. If we do so, we should also specify that these additions must be under a JSON key that is (or is based on) the extension name. (Historical note: The original specification of extensions *only* allowed client processing to add things to clientData, which is symmetric with authenticator processing, but that precluded the former from adding data based on the authenticator outputs.) -- GitHub Notification of comment by arnar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/912#issuecomment-389602285 using your GitHub account
Received on Wednesday, 16 May 2018 17:32:45 UTC