On 2022-03-24 1:57, Tobias Looker wrote:
> What does your code do if it encounters a recipient with int kid?
I agree with this concern but I may be miss understanding the underlying
proposal here. I get the inclination to favour A as the option, but would it
not involve changing the supported data type of a parameter? As an implementer
I can see how some would view this as a breaking change specifically those who
validate the value type of the parameter in accordance with its IANA
registration. I don't think we should be encouraging a pattern where future
specifications are able to redefine the value types supported for a particular
parameter.
In context outside of standards, non-breaking (backward compatible) changes like this is industry
practice. In this case the question is rather if it is a "break-or-make" or
"nice-to-have" feature.
I don't see how you can use something like COSE without having a profile for
actual target.
This however, represents a more fundamental break since the keys are unrelated
to existing OKP keys and algorithms:
https://datatracker.ietf.org/doc/draft-looker-cose-bls-key-representations/
I wouldn't go there at least since it is incompatible with "pluggable"
cryptosystems.
Anders
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
