As I'd written earlier, *if* the working group decides to also support a
payload representation that is not base64url encoded (and I think that's a big
*if*), I believe that it should apply only to the JSON Serialization and use an
alternative member name, so that the current JSON Serialization objects are
unchanged.
For instance, these three alternative representations could all represent the
same JWS Payload:
"payload": "SGVsbG8gd29ybGQ"
"verbatim": "Hello world"
"verbatim": "Hello\u0020world"
As I see it, we shouldn't change the meaning of "payload" at this point,
without as Karen put it, "a strong rationale and a ground swell of working
group support".
-- Mike
From: John Bradley [mailto:[email protected]]
Sent: Wednesday, July 03, 2013 2:25 PM
To: Richard Barnes
Cc: Dick Hardt; Jim Schaad; n-sakimura; Mike Jones; [email protected];
[email protected]
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded
For a JWT the content is a JSON object. For JOSE that restriction doesn't
apply, and the content could be any binary data. That is one of the reasons
people want to put additional JSON in the envelope as they may not be able to
that easily as part of the body.
Just for the record I am one of the people on the side of integrity protecting
headers unless there is a strong reason not to as is the case with multiple
recipients and counter mode encryption.
John B.
On 2013-07-03, at 5:15 PM, Richard Barnes <[email protected]<mailto:[email protected]>>
wrote:
On Wed, Jul 3, 2013 at 1:55 PM, Dick Hardt
<[email protected]<mailto:[email protected]>> wrote:
On Wed, Jul 3, 2013 at 9:04 AM, Richard Barnes
<[email protected]<mailto:[email protected]>> wrote:
On Tue, Jul 2, 2013 at 8:14 PM, Dick Hardt
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
