On Thu, Jun 27, 2013 at 3:24 PM, Richard Barnes <[email protected]> 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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
