Subject: [jose] JWS Unencoded Payload Option -02

From: Mike Jones <[email-masked]>
Date: Mon, 14 Sep 2015 06:28:29 +0000

Draft -02 of the JWS Unencoded Payload Option specification makes these updates:

*        Required that "b64" be integrity protected.

*        Stated that if the JWS has multiple signatures and/or MACs, the "b64" Header Parameter value MUST be the same for all of them.

*        Stated that if applications use content encoding, they MUST specify whether the encoded or unencoded payload is used as the JWS Payload value.

*        Reorganized the Unencoded Payload Content Restrictions section.

*        Added an "updates" clause for RFC 7519 because this specification prohibits JWTs from using "b64":false.

Thanks for the working group feedback that resulted in these improvements.

The specification is available at:

*        https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-02

An HTML formatted version is also available at:

*        http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-02.html

                                                            -- Mike

P.S.  This note is also posted at http://self-issued.info/?p=1456 and as @selfissued<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d>.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 25 Sep 2015 16:15:22 +0300

Hi Mike,

I'm looking at the -02 draft right now, as I was considering
implementing it, at least experimentally for now.

I'm not sure I understand why JWT is mentioned in it. Is this a real use
case? Section 6 effectively implies an alternative JWT encoding, using
normative language, but this conflicts with the JWT RFC which says that
"JWTs are always represented using the JWS Compact Serialization or the
JWE Compact Serialization."

http://tools.ietf.org/html/rfc7519#section-1

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 25 Sep 2015 17:46:31 +0300

Pardon, I got confused that allowing b64:true for JWTs implies a
non-compact serialisation.

Still, I think JWT better not be mentioned in this spec.

Vladimir

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Sep 2015 15:06:10 +0000

Hi Vladimir,

JWT is mentioned only to say that JWTs must not use the alternative "b64":false encoding.  They must be encoded as they always have been.

   JSON Web Tokens (JWTs) [JWT] MUST NOT use "b64" with a "false" value.

I don't understand why this seems to imply an alternative JWT encoding.  Indeed - the intent is the opposite - to prohibit use of the potential alternate encoding.

				Thanks,
				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, September 25, 2015 6:15 AM
To: [email-masked]
Subject: [jose] JWT with JWS Unencoded Payload Options

Hi Mike,

I'm looking at the -02 draft right now, as I was considering implementing it, at least experimentally for now.

I'm not sure I understand why JWT is mentioned in it. Is this a real use case? Section 6 effectively implies an alternative JWT encoding, using normative language, but this conflicts with the JWT RFC which says that "JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization."

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-1&data=01%7c01%7cmichael.jones%40microsoft.com%7c31e01586d3d04e874c6308d2c5ab631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vAxCqdvRt%2fSaOqaYKl1bSTYtMgDQ%2fnvrPJQ1gGSk4mM%3d

Cheers,

Vladimir

_______________________________________________
jose mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40microsoft.com%7c31e01586d3d04e874c6308d2c5ab631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NovTPm6SUrZWlYmPnE%2f6tNPbTR%2f4kHeHBUsjP6mIsNc%3d