[michaelbeaumont]

Previously it wasn't possible to get access to any other extensions the authenticator used.

[AlfioEmanueleFresta]

Thanks for the PR! Do you have any extensions & authenticators in mind, so I could test this?

As for serializing unknown extensions, I like the approach of checking against supported extensions (getInfo response). It's stricter than the spec requires, but still wider than Chromium - which appears to drop all unknown extensions.

As for serializing back extension results however, I think we should only include unknown extension IDs which were part of the request. It prevents accidentally leaking data to the RP which the RP should never see, like largeBlobKey.

Nit: Can we drop non-text CBOR keys? This appears to match what Chromium does and avoids ambiguity when we have both "1" and 1 as keys.

[michaelbeaumont]

Hmm I may have made the scope of this PR too wide. I actually only care about client <-> authenticator CTAP here. I think I added this to GetAssertionRequestExtensions because it was one way to construct a Ctap2GetAssertionRequestExtensions, but it's not really necessary.
I've trimmed the changes down to proto::ctap2 only.

Nit: Can we drop non-text CBOR keys? This appears to match what Chromium does and avoids ambiguity when we have both "1" and 1 as keys.

Added this as well.