This is useful because it means that you can pass both unsigned and signed
content using the same syntax, with no special parsing required. This is used
in practice, for instance, to enable both unsigned and signed request objects,
signed and unsigned ID Tokens, etc.
This is already in widespread use.
I'm kind of surprised that this is coming up now. This has been in JWT since
March 2011 and in the JOSE specs since the working group versions, so it's not
exactly a surprise. (The biggest change was that we moved it from JWT to JWS
in March 2012, at Jim Schaad's suggestion, because it is generally useful
outside of just JWTs.) Yes, an alternative syntax could have been used, but
using the "alg":"none" value to express this works fine in practice. I don't
perceive a compelling reason to change it at this point.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richard Barnes
Sent: Thursday, August 01, 2013 5:08 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Plaintext JWT bug
It has come to my attention that JWT is using "alg":"none" to create "Plaintext
JWTs". Some of us in JOSE believe that this "alg" value should be removed,
because of a risk of downgrade attacks. In order to do that, a suggested
revision to JWT is below. To summarize:
-- Plaintext JWTs are not JWSs.
-- They just have a header and payload (separated by a '.')
-- The header MUST NOT contain "alg", since there's no crypto going on
Thanks,
--Richard
-----BEGIN-----
6. Plaintext JWTs
To support use cases where the JWT content is secured by a means
other than a signature and/or encryption contained within the JWT
(such as a signature on a data structure containing the JWT), JWTs
MAY also be created without a signature or encryption. A plaintext
JWT is the concatenation of a base64url-encoded JWT Header, a
period ('.') character, and the base64url-encoded JWT Claims Set.
The header of a plaintext JWT contains parameters drawn from the
set as the JWS header. However, a JWT header MUST NOT contain an
"alg" header parameter, since no cryptographic processing is being
performed.
6.1. Example Plaintext JWT
The following example JWT Header declares that the encoded object is
a Plaintext JWT:
{"typ":"JWT"}
Base64url encoding the octets of the UTF-8 representation of the JWT
Header yields this Encoded JWT Header:
eyJ0eXAiOiJKV1QifQ
The following is an example of a JWT Claims Set:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Base64url encoding the octets of the UTF-8 representation of the JWT
Claims Set yields this Encoded JWS Payload (with line breaks for
display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Concatenating these parts in this order with aperiod ('.') character
between the parts yields this complete JWT (with line breaks for
display purposes only):
eyJ0eXAiOiJKV1QifQ
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
-----END-----
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
