Clarification: I only support THIRD POLL: B if the new header can be omitted, so that 3-component JWTs are still valid. I don't support this option if backwards-incompatible.
On Wed, Feb 6, 2013 at 9:11 AM, Breno de Medeiros <[email protected]> wrote: > FIRST POLL: Yes > > SECOND POLL: YES > > THIRD POLL: B > > On Wed, Feb 6, 2013 at 9:03 AM, Dick Hardt <[email protected]> wrote: >> FIRST POLL: Yes >> >> SECOND POLL: YES >> >> THIRD POLL: B >> >> On Feb 4, 2013, at 6:48 AM, Karen O'Donoghue <[email protected]> wrote: >> >>> Folks, >>> >>> I am wrestling with how to help drive consensus on the topic of criticality >>> of headers. For background, please review the current specification text, >>> the minutes to the Atlanta meeting (IETF85), and the mailing list >>> (especially the discussion in December with (Subj: Whether implementations >>> must understand all JOSE header fields)). We need to come to closure on >>> this issue in order to progress the specifications. >>> >>> As a tool to gather further information on determining a way forward, the >>> following polls have been created. Please respond before 11 February 2013. >>> >>> Thanks, >>> Karen >>> >>> ******************* >>> FIRST POLL: Should all header fields be critical for implementations to >>> understand? >>> >>> YES – All header fields must continue to be understood by implementations >>> or the input must be rejected. >>> >>> NO – A means of listing that specific header fields may be safely ignored >>> should be defined. >>> >>> ******************** >>> 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.” >>> >>> YES – Add the text clarifying that the “MUST understand” requirement is a >>> requirement on the system as a whole – not specifically on JOSE libraries. >>> >>> NO – Don’t 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? >>> >>> A – Define a header field that explicitly lists the fields that may be >>> safely ignored if not understood. >>> >>> B – Introduce a second header, where implementations must understand all >>> fields in the first but they may ignore not-understood fields in the second. >>> >>> C - Other??? (Please specify in detail.) >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > > > -- > --Breno -- --Breno _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
