Thanks for writing this, Phillip. I’ll repeat a few comments that I think I made to you in person.
First, I would suggest that any extension that changes the signature computation include syntax for declaring that it’s been changed. For instance, it could include a header parameter value like “b64”: false – with the meaning that the payload value is used as-is in the signature computation, rather than being base64url encoded. Putting everything out there, I know that some have also asked for a compact serialization where the signature is computed only over the payload – where all the header parameters are unprotected. This would be particularly useful for detached payloads, because then there’s no need to prepend BASE64URL(ASCII(JWS Protected Header)) || ‘.’ to payload before computing the signature. For truly huge payloads, not having to make a copy of it to do the concatenation can be an implementation advantage. (Matt Miller has told me about some of his experiences related to this in JavaScript.) I would also want this property to be explicitly declared in some manner. To Nat’s question, I would hope that this would normally be used with detached payloads, where the JWS communicated would look like this: Header..Signature – thus avoiding the question of how to represent payloads that are not URL-safe. The answer would simply be “the application knows how to do this”. I think that it’s at least worth considering an extension spec that enables these options, as it could broaden the applicability of JOSE to additional application contexts. I’ll note that when the working group previously considered this question, in the context of http://trac.tools.ietf.org/wg/jose/trac/ticket/23. The thing that makes me personally willing to consider such an extension at this point is that not having to copy a huge detached payload to do the crypto could be the difference between JWS being applicable and not. Thanks for starting this discussion, Philip. -- Mike From: jose [mailto:[email protected]] On Behalf Of Nat Sakimura Sent: Wednesday, March 25, 2015 1:45 PM To: Phillip Hallam-Baker Cc: [email protected] Subject: Re: [jose] Direct Compact Serialization Thanks. So, is it correct to understand that this is intended to the environment that JWS Payload will not be munched by the processing middle-ware etc.? Also, JWS Payload may include linefeed etc. So, the compact serialization may appear like: {"alg":"ES256"}.{"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}.eyJhbGciOiJQUzI....etc.etc.etc...OJ-LWr Is it correct? Best, Nat 2015-03-26 1:14 GMT+09:00 Phillip Hallam-Baker <[email protected]<mailto:[email protected]>>: The revised draft is now up. It is essentially a one pager. Which turns out to be five with the boiler plate and IANA section. http://tools.ietf.org/html/draft-hallambaker-joseunencoded-01 2. Serialization In the JWS Direct Serialization, no JWS Unprotected Header is used. In this case, the JOSE Header and the JWS Protected Header are the same. In the JWS Direct Serialization, a JWS is represented as the concatenation: UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' || (JWS Signature) The calculation of the signature is performed over the octet sequence that corresponds to the concatenation: UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
