[Openid-specs-ab] ACTION NEEDED - Participate in JOSE poll on header criticality

John Bradley ve7jtb at ve7jtb.com
Tue Feb 5 21:00:13 UTC 2013

Dear OpenID Connect participants,
A poll of the JOSE working group is under way that could result in breaking changes to every JWT if it comes out certain ways.  The text of the poll follows my note.  I’d like to ask all of you to please take a few minutes now to respond to the poll, as interested parties in the outcome of the JOSE specs.
Here’s a few comments on the three poll questions, from an OpenID Connect perspective:
FIRST POLL: Should all header fields be critical for implementations to understand?
In the current specs, all header fields are critical to understand, for simplicity and security reasons.  Allowing an explicit list of fields that are OK to not understand, per this answer “NO – A means of listing that specific header fields may be safely ignored should be defined”, could help with future extensibility.  On the other hand, discovery could potentially be used to determine whether an extension is supported and could then only be used when both parties knew that the other understood it.  So a dynamic list of may-be-ignored fields is not necessarily needed for the OpenID Connect use case.  Thus, either outcome is acceptable for Connect (assuming the THIRD POLL comes out OK).
Recommendation on FIRST POLL:  No recommendation based upon Connect’s needs.  Make your own choice on this one based upon how you plan to use the JOSE specs and JWT.
SECOND POLL: Should the result of the first poll be "YES", should text like the following be added? “Implementation Note: The requirement to understand all header fields is a requirement on the system as a whole – not on any particular level of library software. For instance, a JOSE library could process the headers that it understands and then leave the processing of the rest of them up to the application. For those headers that the JOSE library didn’t understand, the responsibility for fulfilling the ‘MUST understand’ requirement for the remaining headers would then fall to the application.”
This poll doesn’t change the meaning of the specs but does provide some additional guidance to implementers.
Recommendation on SECOND POLL:  Vote YES to add the clarifying text.
THIRD POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood?
Answer “A” defines an additional optional header field and makes no changes to existing JWT, JWS, or JWE representations.  Answer “B” would add a fourth dot-separated field to every JWS and a sixth dot-separated field to every JWE.  And “B” provides no semantic capabilities that “A” doesn’t.
Recommendation on THIRD POLL:  Vote for “A – Define a header field that explicitly lists the fields that may be safely ignored if not understood” since that solution would maintain compatibility with your existing implementations.  This is the most important question in the poll.
If you’re not already a member of the JOSE mailing list, you can join athttps://www.ietf.org/mailman/listinfo/jose.  The message to respond to ishttp://www.ietf.org/mail-archive/web/jose/current/msg01448.html.
Thanks for taking the time to do this.
John B. for the OpenID Connect Working Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130205/acad924a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130205/acad924a/attachment.p7s>

More information about the Openid-specs-ab mailing list