That's a more compelling use case -- it's security-specific but only adds to the security validation context.
There may be a case to define optional entries in the JWT header. However declaring that any header you don't understand could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.) So I am not convinced that losing the ability to declare OCSP bindings in JWTs justifies dropping the MUST language. If there is rough consensus that defining optional security fields in the header is prudent from the viewpoint of future spec extensibility then we should devise some simple way to declare a JWT header field optional and exempt _only_those_ from the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < [email protected]> wrote: > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
