You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 droppingSerialize
for requests andDeserialize
for responses. Please let me know if you have any objections.The text was updated successfully, but these errors were encountered: