Re: [jose] #26: Allow for signature payload to not be base64 encoded

[Richard Barnes <[e-mail]>]

On Wed, Jul 3, 2013 at 1:55 PM, Dick Hardt <[e-mail]> wrote:

> On Wed, Jul 3, 2013 at 9:04 AM, Richard Barnes <[e-mail]> wrote:
>
>> On Tue, Jul 2, 2013 at 8:14 PM, Dick Hardt <[e-mail]> 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