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

[Richard Barnes <[e-mail]>]

Hey Dick,

I guess I should have been clearer that I was only talking about the JSON
serialization.  My proposed change would have no impact on the compact
serialization.  Hopefully that answers your questions about separators,
etc.; they payload would just be a normal JSON string.

--Richard


On Thu, Jun 27, 2013 at 7:56 PM, Dick Hardt <[e-mail]> wrote:

>
>
>
> On Thu, Jun 27, 2013 at 3:24 PM, Richard Barnes <[e-mail]> wrote:
>
>> I think there are two separable issues here, both of which Mike and I
>> probably have divergent opinions on :)
>> 1. Syntax: Should it be possible for the "payload" field JWS to be a JSON
>> string (instead of base64) when the payload is simply a UTF-8 string?
>>
>
> One of the goals of the token was that it not require encoding for it to
> be transported in a request. IE that it be safe and SIMPLE to include in an
> HTTP header or in a URL
>
>
>> 2. Crypto: Must the JWS Signing Input be base64url encoded.
>>
>> The current answers to these questions are:
>> 1. It is not possible.  Payload is always base64url encoded.
>> 2. It is always base64url encoded.
>>
>> The answers should be:
>> 1. The payload should not be base64url encoded unless it cannot be
>> represented as a JSON string.
>>
>
> How does an implementation determine which parts are separated? Are '.'
> escaped? Does the implementation need to parse the JSON to determine a
> valid separator? How does it know the end of the JSON? That sounds really
> hard to implement, or I am misunderstanding what you are proposing.
>
>
>
>> 2. The JWS Signing Input should not be base64url encoded unless there is
>> a JWS Protected Header
>>
>> Neither of these are complicated changes:
>> 1. Add a "b64" header parameter that indicates that the payload is
>> base64url-encoded binary, as opposed to a UTF-8 string.  Specify that this
>> parameter is on by default in compact-formatted JWS objects.
>>
>
> And how is the header separated from the payload?
>
>
>>  2. Modify the signing/verification instructions to switch based on the
>> presence of a JWS Protected Header: "If the JWS Protected Header is absent
>> or empty, then the JWS Signing Input is simply the JWS Payload (not
>> encoded).  If the JWS Protected Header has a non-empty value, then the the
>> JWS Signing Input is the concatenation of the Encoded JWS Header, a period
>> ('.') character, and the Encoded JWS Payload"
>>
>> There are two reasons for these, both of which are important to make sure
>> that this spec is applicable to a broad variety of use cases:
>> 1. Compactness.  As Jim notes, quoted strings are shorter than
>> base64url-encoded strings
>>
>
> The tokens are already compact enough.
>
>
>>  2. Crypto-compatibility: Avoiding base64-encoding means that there's
>> nothing JWS-specific about the signature value.  So for example, you could
>> translate a JWS with no protected attributes to a CMS SignedData object
>> with no protected attributes.
>>
>
> Not a useful feature from my point of view.
>
> -- Dick
>