Re: [OAUTH-WG] Nested JWT (was: Re: [jose] "typ":"JWS")

So, first of all, it seems like an abuse of terminology to say "JWT within a JWT", unless you really want to create an infinite recursion.

What's the use case for sign/encrypt/sign, as opposed to just sign/encrypt?

On Jul 6, 2012, at 2:31 PM, Mike Jones wrote:

> A nested JWT is one where a JWT is used as the payload of another JWT, for instance, so you can do sign/encrypt/sign.  See http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-7 and http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5.2.
> 
> I wouldn't use it for multiple signatures - I'd use http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-02 or similar for that.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Richard L. Barnes [mailto:rbarnes@bbn.com] 
> Sent: Friday, July 06, 2012 11:23 AM
> To: Mike Jones
> Cc: Manger, James H; jose@ietf.org
> Subject: Nested JWT (was: Re: [jose] "typ":"JWS")
> 
> Not sure what the appropriate list is for this, so I'm just going to ask it here:
> 
> What is a "nested JWT"?  I'm guessing it's a JWT claim set wrapped in JWS multiple times, as in the example we were discussing earlier?
> 
> Why would you want to do that instead of having parallel signatures?
> 
> 
> 
> 
> On Jul 6, 2012, at 2:19 PM, Mike Jones wrote:
> 
>> Thanks for the thought on this, James.
>> 
>> In the -03 drafts there is now a clear distinction between "typ" (type) - information about this object and the new "cty" (content type) - information about the secured object.  Besides being semantically cleaner, this also simplified nested JWTs.
>> 
>> I then was able to make changes in the spirit of the ones you suggested below, although using slightly different wording in some cases.
>> 
>>                                                                -- 
>> Mike
>> 
>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>> Sent: Tuesday, May 15, 2012 5:40 PM
>> To: Mike Jones; jose@ietf.org
>> Subject: RE: "typ":"JWS"
>> 
>>>> draft-ietf-jose-json-web-signature-02 §7.2 registers the "JWS" type 
>>>> value (for the "typ" header field) . Perhaps "typ":"JWS" is more 
>>>> useful in a JWE header when encrypting signed content (sign-then-encrypt). If this is the intention, then mentioning the "JWS" type value when defining the "typ" header for a JWS is misleading. It would be better to mention it where the JWE spec defines "typ".
>>>> .
>> 
>>> Your second paragraph correctly describes the intended usage.  For instance, see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.1 for this usage in action.  The value is registered per the working group decision relating "typ" values to MIME types.
>> 
>> Good. So let's say that. Suggested text changes:
>> 
>> * draft-ietf-jose-json-web-signature-02, section 4.1.8 "typ" (Type) Header Parameter: delete the 2nd sentence because signing a signature is not what we are talking about (and JWS-JS recommends a different approach for multiple signatures anyway).
>> 
>> * section 7.1 Registration of application/jws MIME Media Type: add a phrase explicitly stating the syntax (since the spec mentions two: compact, and JWS JS) so the section says:
>>  This specification registers the "application/jws" MIME Media Type [RFC 2045]
>>  to identify content that uses the JWS compact serialization.
>> 
>> * section 7.2 Registration of "JWS" Type Value: mention the intended use of encrypting signed content by adding this sentence.
>>  The "typ" parameter can be set to "JWS" in a JSON Web Encryption [JWE] header when encrypting signed content.
>> 
>> * draft-ietf-jose-json-web-encryption-02, section 4.1.13 "typ" (Type) Header Parameter, section 11.1 Registration of application/jwe MIME Media Type, section 11.2 Registration of "JWE" type Value: make equivalent changes.
>> 
>> --
>> James Manger
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 