For a JWT the content is a JSON object. For JOSE that restriction doesn't apply, and the content could be any binary data. That is one of the reasons people want to put additional JSON in the envelope as they may not be able to that easily as part of the body.
Just for the record I am one of the people on the side of integrity protecting headers unless there is a strong reason not to as is the case with multiple recipients and counter mode encryption. John B. On 2013-07-03, at 5:15 PM, Richard Barnes <[email protected]> wrote: > On Wed, Jul 3, 2013 at 1:55 PM, Dick Hardt <[email protected]> wrote: > On Wed, Jul 3, 2013 at 9:04 AM, Richard Barnes <[email protected]> wrote: > On Tue, Jul 2, 2013 at 8:14 PM, Dick Hardt <[email protected]> wrote: > Hi Richard, thanks for the example, some comments and questions: > > To clarify, in the JSON (non-compact) version, the payload is restricted to > being a string? ie. it cannot be a JSON object? If so, that seems really > limiting. > > The payload can be anything that can be expressed as a JSON string. The > payload needs to be serialized, not as a JSON entity (object, array, number), > because it's going to be input to a signature verification operation (so it > needs to be canonical). Every JSON string has a unique representation in > UTF-8, so we can use that for anything that can be put into a string. > > So it is just a string that has had control characters escaped > (",\,/,backspace, formfeed, newline, carriage return, horizontal tab) > > This is in sharp contrast to the compact form that takes a JSON object. > > I have a hard time understanding how this even fits into the WG Charter as > your proposal is not transporting JSON. (yes, a JSON string is part of JSON, > but it does not have the value proposition that a JSON object has) > > Am I missing something? > > -- Dick > > Yeah, I think you might be a little confused. Right now, the payload can be > any octets -- JSON, UTF-8, EBCDIC, JPEG, QuickTime, whatever. That's true for > both the JSON and compact serializations. And that's why in general, the > payload has to be base64-encoded to be able to carry it in JSON. > > This proposal is just saying that when you have content that can be > represented as UTF-8 (e.g., JSON or HTML), you don't have to base64 encode > it, you can just stick it in a JSON string. > > --Richard > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
