Re: [jose] Whether implementations must understand all JOSE header fields

["Manger, James H" <[e-mail]>]

James said:
>> I would also appreciate your thoughts on whether someone can extend JWS by specifying: when the “zip” field is present in a JWS the content is compressed.
That looks legitimate with the current “MUST understand or reject” rule. I think it is likely, however, that such an extension will cause security problems. Some implementations will confirm that “zip” is on the list of known standard fields, but will ignore it in the JWS processing code.

Mike said:
> One would define “zip” in a JWS in the normal way that extensions are made to IETF specs – you’d write a spec defining the meaning for it and register the “zip” value in the IANA JSON Web Signature and Encryption Header Parameters registry for JWS usage.


Lets ignore the process for now (IETF, IANA…), the issue is whether this style of extension is sensible: an extension that indicates a change of semantics by the presence of a new field. A style that the “MUST understand everything” rule encourages.
My argument is that this style is too dangerous a way to indicate new semantics. When changing semantics (as “zip” does) it would be much better to change a field we are confident implementations will be looking at, as opposed to relying on them to notice a new field.

--
James Manger