Re: [webauthn] agl doesn't understand extensions

I'm fairly confused myself, so I did some digging in the history because as [originally proposed](https://github.com/fido-alliance/fido-2-specs/commit/f4e9e1c782ef96f9cca3c6a0540bd2e4a5cb9393), extensions were pretty simple.

 - Extensions take only one input, a JS object.
 - The client processing defines
   - (optionally) A JSONable value to be added to clientData
   - (optionally) A CBORable value to be sent as the extension input to the authnr
 - Authenticator processing defines (optionally) an output value to be embedded in the signed data.

> If forced to pose the question in the form of a change: what objections arise from removing the clientExtensions and authenticatorExtensions from CollectedClientData?

This was introduced in [this commit](https://github.com/w3c/webauthn/commit/34e0836c0c5378c86099ea5184746638ca2731c9) for which I cannot find any PR or discussion. Previously the clientData only contained one field for a map of the optional client data additions made by extensions. I think I would have disagreed with that change if I reviewed it, but maybe there is a good reason that was discussed on the calls. Mike, do you remember?

Client was allowed to ignore any extension, but also to forward the input object to the authnr if the canonical JSON-CBOR conversion (from RFC7049) was possible.

Extension definitions themselves were expected to include sentinels if necessary to indicate to the RP that processing took place. This was explicitly called out, see e.g. [here](https://github.com/w3c/webauthn/commit/c05d78629156b9b99faedcd03151cc8cefa7ce91#diff-117d6498d2aa8019cc0abf5eeb87a9faR1441), but abandoned in [this commit](https://github.com/w3c/webauthn/commit/04ccbfbdf63342c974618cc2534cea5e2080e627).

-- 
GitHub Notification of comment by arnar
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/803#issuecomment-366111196 using your GitHub account

Received on Friday, 16 February 2018 00:44:10 UTC