Allow unexpected fields

[AlfioEmanueleFresta]

We're using serde-indexed in libwebauthn, which implements the platform side of the CTAP spec.

When deserializing, the CTAP spec mandates unknown fields should be ignored. Without this, we just can't use serde-indexed, in favour of parsing structures manually.

I think this change will be safe to merge as backwards compatible because:

• All working inputs will continue working;
• Ignoring unexpected fields is the default behaviour of #[derive(Deserialize)], so it can be considered expected behaviours;
• Behaviour for unexpected inputs currently does not specify otherwise.

Cc @robin-nitrokey @sosthene-nitrokey for review

[sosthene-nitrokey]

Relevant part of the CTAP spec:

fido-client-to-authenticator-protocol-v2.2 § 8

if map keys are present that an implementation does not understand, they MUST be ignored. Note that this
enables additional fields to be used as new features are added without breaking existing implementations

[robin-nitrokey]

Thanks for the PR! The change looks good to me, I just want to check if it has any effects on the binary size of our firmware. Potentially, this could pull in parts of the deserialization library that are otherwise unused.

[sosthene-nitrokey]

It would be nice to have an opt-out (like #[serde(deny_unknown_fields)].

[robin-nitrokey]

This change only has a small impact on the firmware binary size. I’d also like to have a deny_unknown_fields options but that can also be implemented in a separate PR.

@AlfioEmanueleFresta Please update the changelog for this change.

[AlfioEmanueleFresta]

Thank you both!

@robin-nitrokey done - I took the liberty of drafting the 0.1.2 changelog for release later today, I hope that works.

[robin-nitrokey]

Thanks! @sosthene-nitrokey Are you okay with considering this a bugfix and releasing it as v0.1.2 or do you see it as a breaking change?

[sosthene-nitrokey]

I think it should be a breaking release but since according to lib.rs we're the only users I'm fine with a minor release. Might be great to include #14 and #16 in it too though.

[robin-nitrokey]

@sosthene-nitrokey Then let’s do it properly and make a breaking release v0.2.0 with this change. Then we can also pull in #21.