JSON Web Token (JWT)
Note: This ballot was opened for revision 26 and is now closed.
(Kathleen Moriarty) Yes
(Jari Arkko) No Objection
(Richard Barnes) (was Discuss) No Objection
Comment (2014-10-10 for -27)
Abstract. Welsh is the only language I know of in which "w" is a vowel. According to Wikipedia, then, "JWT" should pronounced "joot" :) Section 2. It seems like "Unsecured JWT" should simply be defined as "A JWT carried in an Unsigned JWS." Section 4.1. I'm a little surprised not to see a "jwk" claim, which would basically enable JWTs to sub in for certificates for many use cases. Did the WG consider this possibility? Section 7. It would be good for this document to pass on the note from JWS about selecting which algorithms are acceptable, and in particular, whether unsecured JWTs are acceptable.
Alissa Cooper (was Discuss) No Objection
Comment (2014-11-04 for -30)
Thanks for taking care of my DISCUSS points.
Spencer Dawkins No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2014-11-12 for -30)
I've cleared as a number of people have said that not having "none" as MTI would cause problems for their implementations. That is sad but blocking would be wrong. ---- old comments below - abstract: 2nd sentence isn't needed here, in intro would be fine. - 4.1.7: maybe worth adding that jti+iss being unique enough is not sufficient and jti alone has to meet that need. In X.509 the issuer/serial has the equivalent property so someone might assume sequential jti values starting at 0 are ok. - section 6: yuk - again I think the secdir comments are being handled by Kathleen and the authors.
(Brian Haberman) (was No Record, No Objection) No Objection
(Joel Jaeggli) No Objection
(Barry Leiba) (was Discuss) No Objection
Comment (2014-10-21 for -29)
All of my comments have been resolved on or before version -29; thanks.
(Ted Lemon) No Objection
Comment (2014-10-02 for -27)
The suggested pronunciation of JWT is the same as the English word "jot". I would have gone with "jute". :) Also, this doesn't belong in the abstract. It appears to have crept in as a result of cutting and pasting the introduction into the abstract. Is there any reason not to just require this: While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, normally senders should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions. When does it make sense not to do it this way?
(Pete Resnick) No Objection
Comment (2014-10-02 for -27)
Others have said all I might say. I do not object to "joots". :-)