Re: [jose] Distinguishing signed, encrypted, and unprotected tokens

["Manger, James H" <[e-mail]>]

I suggested:
>>> * 3 dots (4 segments) => JWE
>>> * 2 dots (3 segments) => JWS
>>> * 1 dot  (2 segments) => unprotected payload (<header>.<payload>)

Jim wrote:
>> What happens if you are distinguishing based on the number of dots and 
>> then you move to a new encoding format that is not dot separated?

Hang on Jim, of course interop fails if you change syntax.


Mike said:
> Indeed, we already have a JSON format proposed in response working
> group input with no dots.  See these specs:
>	http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-01
>	http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serialization-01

Neither of these 2 specs talk about having a field that can be a JWE-JS, or a JWS-JS, or an (undefined) Plain-JS and having to distinguish them -- which is the *-JS equivalent to the dot-separated-B64 issue we are discussing.

The *-JS alternatives are illustrative.
JWS-JS:  {"headers":[<h1>,<h2>...], "payload":<p>, "signatures":[<s1>,<s2>...]}
JWE-JS:  {"headers":[<h1>,<h2>...], "encrypted_keys":[<k1>,<k2>...],
          "ciphertext":<c>, "integrity_values":[<s1>,<s2>...]}

The *-JS syntaxes have an *array of headers*. Are you supposed to use the "alg" value from the first header, the last header, check all headers? Or look for an "enc" header field in the first, last, or every header? I hope they are not inconsistent.

A better alternative would be to leave the headers alone and look for an "encrypted_keys" field. Another alternative could be changing the "headers" label to "jws" or "jwe" or "header" (when unprotected).

If you want to send an unprotected payload in *-JS syntax, can you omit the "integrity_values" field, or send an empty array, or send an array with 1 value that is an empty string? The first option sounds best, but the last option is the equivalent of the "alg":"none"-fake-signature method in JWT.


I really think we need -- in the JOSE specs -- to defined the packaging of signed, encrypted, or unprotected content in a way that is trivial to distinguish these 3 modes. If we have another packaging syntax (eg *-JS) it also needs to support these 3 modes and make them trivial to distinguish.

This has nothing to do with a JSON object carrying a bunch of claims (for which the OAuth group might be more appropriate).


--
James Manger