JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-32

Note: This ballot was opened for revision 26 and is now closed.

(Kathleen Moriarty; former steering group member) Yes

Yes ( for -26)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -27)
No email
send info

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2014-11-04 for -30)
No email
send info
Thanks for taking care of my DISCUSS points.

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2014-10-21 for -29)
No email
send info
All of my comments have been resolved on or before version -29; thanks.

(Brian Haberman; former steering group member) (was No Record, No Objection) No Objection

No Objection ( for -27)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -27)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -27)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -27)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (2014-10-02 for -27)
No email
send info
Others have said all I might say. I do not object to "joots". :-)

(Richard Barnes; former steering group member) (was Discuss) No Objection

No Objection (2014-10-10 for -27)
No email
send info
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.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -27)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2014-11-12 for -30)
No email
send info
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.

(Ted Lemon; former steering group member) No Objection

No Objection (2014-10-02 for -27)
No email
send info
   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?