As I think you know, there's an open issue in the JOSE working group about
whether all header fields must be understood or whether a mechanism should be
defined to specify which header fields may be safely ignored if not understood.
John Bradley and Richard Barnes and I have been drafting a note about these
choices to the JOSE working group, which I expect should go out any day now.
Per my reply to your note on the OAuth list, the intended meaning is "The use
of this header parameter is OPTIONAL." I'll plan to clarify this in the next
version of the specifications.
Thanks again,
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Hannes
Tschofenig
Sent: Monday, November 26, 2012 3:07 AM
To: [email protected]
Cc: Hannes Tschofenig
Subject: [jose] Extensibility (was "Criticality")
Hi all,
doing my shepherd writeup of some of the OAuth WG documents I was wondering how
the extensibility story for these JSON-based documents should look like given a
statement like this: "Implementations MUST understand the entire contents of
the header; otherwise, the JWS MUST be rejected."
Absent a "feature discovery" mechanism I am curious whether any extension is
actually possible.
(Funny enough then all individual parameters then say "This header parameter is
OPTIONAL.")
Since this type of extensibility feature does not seem to a be a new concept I
am curious how it has been handled (successfully) in other specifications.
Ciao
Hannes
PS: I remember that this has been discussed during the meeting but I do not
know what the outcome of the discussion was. The meeting minutes do not seem to
be available yet.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
