Mike Jones wrote:
>one of the sources of confusion is the differences between the JOSE and COSE
>definitions, which I consider to be unfortunate.
Yes, COSE has already aligned with how the rest of the IETF like BCP 195
(RFC8996 and RFC9325) uses the term deprecated. I think it would be good if
Thanks to those who provided references to the definitions of the fields for
JOSE and COSE. Indeed, as Orie and I have discussed, one of the sources of
confusion is the differences between the JOSE and COSE definitions, which I
consider to be unfortunate.
In JOSE, there's a clear distinction b
Jeremy O'Donoghue wrote:
>It is not clear to me where the set of possible values for “Implementation
>Requirements” is defined
The set of possible values for "JOSE Implementation Requirements" is defined in
RFC 7518. The currently allowed values are Required, Recommended, Optional,
Deprecated,
Having read the I-D and RFC8996, I agree with John and Göran.
Strong “-1” on the term “deprecated”
The meaning of the term “deprecated” needs to be well-defined before it can be
used. It seems to me that definition used in RFC8996 and RFC9325 is very
clear-cut. The text says:
“Removing suppor
Mike Jones wrote:
>What deprecation DOES do is indicate that new applications and specifications
>should choose the >fully-specified algorithms instead.
What do you base this on?
My understanding is that JOSE and COSE documents does not define the term
“deprecated” at all. Typical use of the t
