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
