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