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:[email protected]] > Sent: Friday, July 06, 2012 11:23 AM > To: Mike Jones > Cc: Manger, James H; [email protected] > 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:[email protected]] >> Sent: Tuesday, May 15, 2012 5:40 PM >> To: Mike Jones; [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
