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

[Dick Hardt <[e-mail]>]

I'm guessing that per: http://datatracker.ietf.org/wg/jose/charter/

- A Standards Track document specifying a representation of encrypted
data using JSON data structures, where the data to be protected
includes (but is not limited to) JSON data structures.

You are looking to use JSON as the wrapper for a JSON string.

Interesting, but I think that should be a different document as it solves
very different use cases and the processing is very different.



On Wed, Jul 3, 2013 at 2:15 PM, Richard Barnes <[e-mail]> wrote:

> 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
>
>