Re: [jose] alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

Mike Jones <> Wed, 17 September 2014 16:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C341E1A04BC; Wed, 17 Sep 2014 09:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EHYfous8WBXj; Wed, 17 Sep 2014 09:41:32 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::720]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA04D1A04B9; Wed, 17 Sep 2014 09:41:31 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.13; Wed, 17 Sep 2014 16:41:08 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Wed, 17 Sep 2014 16:41:07 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Wed, 17 Sep 2014 16:41:07 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Wed, 17 Sep 2014 16:40:44 +0000
From: Mike Jones <>
To: Warren Kumari <>, Richard Barnes <>
Thread-Topic: alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
Thread-Index: AQHP0mwjMH5fKbfHa0qoJPYCQJJBhZwFhKbQ
Date: Wed, 17 Sep 2014 16:40:42 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439B941EA6TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(13464003)(199003)(189002)(51444003)(24454002)(55846006)(26826002)(19300405004)(106116001)(19580395003)(44976005)(83322001)(19617315012)(80022003)(85852003)(64706001)(69596002)(74662003)(77982003)(19580405001)(66066001)(74502003)(79102003)(81542003)(90102001)(15975445006)(84676001)(81156004)(86362001)(86612001)(76482002)(77096002)(92726001)(20776003)(50986999)(83072002)(106466001)(512874002)(85306004)(54356999)(21056001)(99396002)(87936001)(4396001)(76176999)(92566001)(230783001)(6806004)(31966008)(46102003)(68736004)(15202345003)(2656002)(97736003)(107046002)(104016003)(71186001)(95666004)(84326002)(85806002)(33656002)(81342003)(16236675004)(19625215002)(372894003)(9078065003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0776;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0337AFFE9A
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, Brian Campbell <>, "" <>, "" <>, "" <>
Subject: Re: [jose] alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Sep 2014 16:41:36 -0000

Yes, this was already extensively discussed.  It was covered in issue #36 and the related working group e-mail thread.  It was also a topic during multiple interim working group calls.  As noted by Karen O’Donoghue (one of the chairs) in the issue description “Note: There was extensive discussion on the mailing list, and the rough consensus of the working group was to leave "none" in the document.”  As part of the resolution agreed to by the working group, the security considerations text at was added.

                                                            -- Mike

From: Warren Kumari []
Sent: Wednesday, September 17, 2014 4:40 AM
To: Richard Barnes
Cc: Brian Campbell; Mike Jones;;;;
Subject: Re: alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

On Tuesday, September 16, 2014, Richard Barnes <<>> wrote:
I will re-iterate here my strong preference that an "unsecured" or "plaintext" JWS object be syntactically distinct from a real JWS object.  E.g. by having two dot-separated components instead of three.

So, *I* was just grumping about the term used in the draft, but yes, these should (IMO, etc) be different.

I'm also still uncomfortable about the "you can have the same information in the "secured" and "unsecured" section, but the secured one shold be trusted more bit. This seems like it will end in fail. (Apologies if this was already discussed and I missed it, and for rushed tone of mail, traveling...)


Beyond that, seems like just shuffling deck chairs.

On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell <<javascript:_e(%7B%7D,'cvml','');>> wrote:
cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.

I agree that "plaintext” is not the most intuitive wording choice and that "unsecured" might better convey what's going on with the "none" JWS algorithm.
Mike mentioned that, if this change is made in JWT, there are parallel changes in JWS. But note that there are also such changes in JWA (more than in JWS actually).

On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones <<javascript:_e(%7B%7D,'cvml','');>> wrote:

-----Original Message-----
From: Warren Kumari [<javascript:_e(%7B%7D,'cvml','');>]
Sent: Monday, September 01, 2014 3:40 PM
Subject: Review of: draft-ietf-oauth-json-web-token

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.

I’ve discussed this with the other document editors and we agree with you that “plaintext” is not the most intuitive wording choice in this context.  Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think that “Unsecured JWT” is probably the preferred term, since JWTs that are JWEs are also unsigned, but they are secured.  Working group – are you OK with this possible terminology change?  (Note that the parallel change “Plaintext JWS” -> “Unsecured JWS” would also be made in the JWS spec.)

jose mailing list<javascript:_e(%7B%7D,'cvml','');>

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.