Be ye not afraid -- I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Disclaimer: I know next to nothing about JOSE. In reading this document I also went off and read some other JOSE work / WG documents. The main thing that I learnt was that them thar JOSE folk sure do like their acronyms.. :-) My unfamiliarity with JOSE means that, unlike what the above boilerplate says, you should treat these less seriously than any other last call comments! Summary: Needs some work, nothing major. Notes: In a number of places the document says things like: "If any of the listed steps fails then the JWT MUST be rejected for processing." - does it actually *mean* to reject a JWT? What should an application do when it rejects a JTW (yes, I realize that this is somewhat application specific, but a general "Explode, killing everybody inside" vs "Simply pretend you didn't notice this" would be helpful). I'm a little confused by something in the Terminology section (Section 2): Plaintext JWT A JWT whose Claims are not integrity protected or encrypted. The term plaintext to me means something like "is readable without decrypting / much decoding" (something like, if you cat the file to a terminal, you will see the information). Integrity protecting a string doesn't make it not easily readable. If this document / JOSE uses "plaintext" differently (and a quick skim didn't find anything about this) it might be good to clarify. Section 6 *does* discuss plaintext JWTs, but doesn't really clarify the (IMO) unusual meaning of the term "plaintext" here. MACed does not seem to be a well known term - surprisingly enough even MAC doesn't have an asterisk at https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt Section 4: "... recipients MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name..." This somewhat made me itch - some implementations will reject a given JWT, some will accept it -- I know very little about parsing JSON, but could you suggest which an implementation should prefer? Can I instruct standard parsers to do X in this case? Section 4.1.4. "exp" (Expiration Time) Claim (and other time based Claims: What should my behavior be if I simply don't know what the time is? (I'm just a dumb device, and my RTC is claiming it is Jan1st, 1970) - I'm assuming I must not process this JWT? Does this create bootstrapping issues? 5.3. Replicating Claims as Header Parameters This section scares me, and I hope I'm simply not understanding what is being proposed. If you send the unencrypted version of some encrypted Claims some implementations will make important security decisions based upon those unencrypted claims, even if you tell them in a serious voice not to. http://xkcd.com/1181/ Also, the SHOULD in "If such replicated Claims are present, the application receiving them SHOULD verify that their values are identical, ..." - why is this not a MUST? And if an application *does* compare them and they are not identical, what should it do? Perhaps a much stronger justification for carrying 2 copies of the data is in order. Editorial: The intro is almost identical to the abstract. Making the abstract more abstract, or the intro more introductory (I have no idea what many of the acronyms were!) would be nice. Something short explaining what a JWT is, why I'd like one,what they get used for, why I should keep reading this document would be very helpful - basically a background type section... Nits: Abstract O: is a compact URL-safe means P: is a compact, URL-safe means 3. JSON Web Token (JWT) Overview O: The contents of the JOSE Header describe P: Spell out JOSE; first use in document as far as I could see 5.2 "cty" (Content Type) Header Parameter O: normal case where nested signing P: normal case in which nested signing 8. Implementation Requirements O: For instance, an application might require support for encrypted JWTs and Nested JWTs; another might require support P: For instance, one application might require support [...], while another might require support [...] 11. Security Considerations O: The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here. P: The entire list of security considerations is beyond the scope of this document. R: A few of the considerations are already listed above; we don't need to restate that they are listed here -- and if we do, the assumption is that said list would follow, not be above. 11.2 Signing and Encryption Order O: While syntactically, the signing and encryption operations for Nested JWTs may be applied in any order, P: While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf