Thanks for your review, Stephen. Replies inline below... > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Thursday, December 17, 2015 12:20 PM > To: The IESG <[email protected]> > Cc: [email protected]; Mike Jones > <[email protected]>; Jim Schaad <[email protected]>; > [email protected]; [email protected]; [email protected] > Subject: Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input- > options-08: (with DISCUSS and COMMENT) > > Stephen Farrell has entered the following ballot position for > draft-ietf-jose-jws-signing-input-options-08: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > The "crit" point raised in the gen-art review and maybe elsewhere is I think > correct but I don't think section 6 of -08 is a good resolution of this topic. > However, I'll clear if this is the WG consensus but it's hard to know that's > the > case for text just added yesterday. To resolve this discuss we just need to > see > what the WG list says about the new text.
Jim's shepherd write-up at https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/shepherdwriteup/ records the working group's desire to not require the use of "crit" when it isn't needed. He wrote: "(6) The fact that there are two different versions of encoding that produce the same text string for signing is worrisome to me. The WG had the ability to address this when producing the JWS specification and decided not to do so that time. In this document, the desire to allow for things to be smaller has lead to the fact that the b64 and crit headers can be omitted as being implicit. This was the desire of the WG, but I personally feel that it is the wrong decision." > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - abstract: the description of the update to 7519 is odd. It seems to be > saying > "Here we define a thing. This specification updates 7519 to say you must not > use this thing." but prohibiting is an odd verb to use there. (Since it wasn't > previously there to be allowed or not.) Would you like this text better? "This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification." Or do you think this spec doesn't need to have the "Updates 7519" clause at all? People seemed split on whether this was needed or not. > - section 6: "It is intended that application profiles specify up front > whether" > "intended" is very wishy washy and "up front" > makes no sense at all. How about this wording change? "It is intended that application profiles specify up front whether" -> "Application profiles should specify whether" Thanks again, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
