<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Dear OpenID Connect participants,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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 <span style="color: red; ">please take a few minutes now to respond to the poll</span>, as interested parties in the outcome of the JOSE specs.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Here’s a few comments on the three poll questions, from an OpenID Connect perspective:<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">FIRST POLL: Should all header fields be critical for implementations to understand?<o:p></o:p></span></tt></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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 “<tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">NO – A means of listing that specific header fields may be safely ignored should be defined</span></tt>”, 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).<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">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.”</span></tt><o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">This poll doesn’t change the meaning of the specs but does provide some additional guidance to implementers.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Recommendation on SECOND POLL:  Vote YES to add the clarifying text.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">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?</span></tt><o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.  <span style="color: red; ">This is the most important question in the poll.</span><o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">If you’re not already a member of the JOSE mailing list, you can join at<a href="https://www.ietf.org/mailman/listinfo/jose" style="color: purple; ">https://www.ietf.org/mailman/listinfo/jose</a>.  The message to respond to is<a href="http://www.ietf.org/mail-archive/web/jose/current/msg01448.html" style="color: purple; ">http://www.ietf.org/mail-archive/web/jose/current/msg01448.html</a>.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Thanks for taking the time to do this.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">John B. for the OpenID Connect Working Group<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div></body></html>