Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Wed, 30 May 2012 03:35:30 -0700

Hi guys,

I have to say I quite liked James Manger's comment. Giving plain
whatever-data with JSON Web Header "first-class-citizen" status is not
without merit. As a programmer I love it when the language + structure
of a spec is crafted in such a way as to flow by itself into well
structured code. For instance, taking the terms of a spec and turning
them into a nice hierarchy of classes.

In our Nimbus-JWT library PlainJWT, SignedJWT and EncryptedJWT all
extend the base class JWT. From a programmer's perspective this is the
natural way of seeing JWT protection. We do not have a
SignedJWT.isPlain() or similar method to convey the meaning of a plain
JWT (and have undefined method for all signature related operations).

If naming is the problem, then let's acknowledge this and then we'll sit
down and meditate on a suitable term for this unprotected-data-with JSON
Web header.

And if we need a common name for this header, why not call it JSON Web
Header (JWH) :-)

Vladimir

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

-------- Original Message --------
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
From: Mike Jones <[email-masked]>
Date: Tue, May 29, 2012 5:34 am
To: "Manger, James H" <[email-masked]>, Sean Turner
<[email-masked]>, Vladimir Dzhuvinov / NimbusDS
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Actually, the third mode already exists, and is parallel, by design, to
the signed/MACed and encrypted modes. No restructuring is necessary to
achieve this. The three are all unambiguously distinguished by the value
of the "alg" parameter (the value of which MUST be understood, or else
the structure must be rejected).

 -- Mike

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, May 28, 2012 5:23 PM
To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

"alg":"none" certainly doesn't belong in the OAuth JWT spec that defines
a format for identity claims.

Sticking "alg":"none" in a JOSE core spec is not the answer, however.
The solution is to make unprotected data a first-class citizen alongside
signed data (JWS) and encrypted data (JWE) in the (embarrassingly
unnamed) top-level JOSE structure that can hold any of these 3 forms of
data -- and is the JOSE structure that other specs will use.

Having JWS and JWE in separate specs means there isn't an obvious place
to specify the top-level JOSE structure (so it is done awkwardly in the
OAuth JWT spec). We could add two more JOSE specs: JWP
(plain/unprotected data) and JOSE (top-level structure = {JWS|JWE|JWP}).
I think a better approach would be to (re-)combine JWS and JWE. The
combined spec would include unprotected data as a third mode. The
algorithms spec can remain separate.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mike Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

For what it's worth, "alg":"none" was moved from JWT to JWS based upon
Jim Schaad's suggestion in
http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for
closing the open issue about whether it belongs in JWT or JWS. In it, he
wrote:

[JLS] If it is believe that a parameter this list is going to be
"commonly" used by many different profilers, then I believe that the
core items needs to be done the in the base specification.

I believe his rationale was correct and has been proven out by events.
At this point I now of several usages of "none" both within JWTs, and
significantly, in at least one context where the structure is a JWS but
*not* a JWT. I believe Jim was right to suggest that "alg":"none"
belongs in the Algorithms specification.

 Best wishes,
 -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sean Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> Section 3.1
>>>>>
>>>>> 1. I am not overly happy with the existence of a "none" algorithm. 
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This 
>>> makes plain JWTs nimbler too. I see no problem with having empty 
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the 
>>> rest of the parameters which don't have "none" values (we don't have 
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS, 
>>> section 4.1.6) which no longer has the (optional) "none": it's 
>>> either "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume 
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON 
> Web Token (JWT) spec where the concept of plain tokens is originally 
> introduced. Therefore, the case of a missing "alg" should fall outside 
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative
reference. If draft-ietf-jose-json-web-algorithms, is going to retain
the section on creating plaintext JWS then it's worth saying how empty
would be handled - and then you can avoid the reference.

spt