Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Fri, 18 May 2012 00:31:24 -0700

I suppose this recommendation is part legacy, part an effort to make
things future-proof.

When I first started work on the Nimbus-JWT library, that was in early
2012, the drafts specified three dots for plain, signed and encrypted
JWTs. So there was no way to figure out the type from the delimiter
count and the "alg" value had to be inspected. 

I agree that "alg":"none" is superfluous and could be made optional.

Cheers,

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

-------- Original Message --------
Subject: [jose] Distinguishing signed, encrypted, and unprotected
tokens
From: "Manger, James H" <[email-masked]>
Date: Thu, May 17, 2012 5:57 am
To: "[email-masked]" <[email-masked]>

draft-jones-json-web-token-10#section-5 suggests looking at the "alg"
value in the header to distinguish whether you have a JWE, JWS, or plain
JWT.

Wouldn't it be better to distinguish these cases by the number of dots:
* 3 dots (4 segments) => JWE
* 2 dots (3 segments) => JWS
Then we could use 1 segment for a plaintext JWT
* 0 dots (1 segment) => Plaintext JWT (base64url-encoded JWT Claim Set)

Benefits:

1. JWT spec doesn't need to confusingly specify the "JWT header" as
though it is a separate thing from a JWS or JWE header. Rules are
specified for the JWT header (unique names, no duplicates, all
understood or reject, JWT-specific "typ" definition) but surely these
should just be the JWS or JWE header rules as appropriate.

2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for
{"alg":"none"}) on plaintext JWTs

3. Top-level code doesn't need to know all sig & enc algs; can leave
that to signing & encryption libraries

4. Don't need to split, decode, parse header before passing JWT onto JWS
or JWE processing (which may well split, decode, and parse the same
stuff all over again) [eg
https://github.com/NimbusDS/Nimbus-JWT/blob/master/src/com/nimbusds/jwt/JWT.java#LC137]

5. Less risk that "none" is implemented as a proper JWS signature
verification algorithm and accidentally allows unsigned code to pass
security gates.

--
James Manger

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose