Some parts of this crate try to accommodate both the authenticator side and the platform side, even though it is only used by fido-authenticator (at least on crates.io).
For example, many (or all?) request structs also implement Serialize even though authenticators will only deserialize requests, and vice versa for responses.
This increases the generated code, maintenance and test effort; and keeping compatibility for platforms can lead to suboptimal choices for authenticators. For example, for an authenticator, it is not necessary to handle unknown enum values in responses.
Therefore, I would like to drop support for platforms in ctap_types, at least until there is an actual demand for it. This mainly means dropping Serialize for requests and Deserialize for responses. Please let me know if you have any objections.
Some parts of this crate try to accommodate both the authenticator side and the platform side, even though it is only used by
fido-authenticator(at least on crates.io).For example, many (or all?) request structs also implement
Serializeeven though authenticators will only deserialize requests, and vice versa for responses.This increases the generated code, maintenance and test effort; and keeping compatibility for platforms can lead to suboptimal choices for authenticators. For example, for an authenticator, it is not necessary to handle unknown enum values in responses.
Therefore, I would like to drop support for platforms in
ctap_types, at least until there is an actual demand for it. This mainly means droppingSerializefor requests andDeserializefor responses. Please let me know if you have any objections.