In the spirit of compromise, and to help further the discussion on this topic,
I thought I'd suggest a possible syntax for the JWS JSON Serialization for
representing an unencoded payload as a JSON string. One way of allowing either
encoded or unencoded payloads would be to use different JSON member names for
them. For instance, one could allow either of these names, but not both, in
any particular JWS using the JSON Serialization:
"payload" - Contains base64url encoded JWS Payload representation
"verbatim" - Contains unencoded JWS Payload representation
So then, for instance, these three alternative representations would all
represent the same JWS Payload:
"payload": "SGVsbG8gd29ybGQ"
"verbatim": "Hello world"
"verbatim": "Hello\u0020world"
As for the signature computation, in the "payload", case there would be no
change from the present. In the "verbatim" case, I assume that the logical
thing to do would be to use the octets of the UTF8 representation of the
payload string in the signing input - in this example, 72 101 108 108 111 32
119 111 114 108 100.
This approach would avoid the problem I had discussed earlier of there being a
default that is different than the Compact Serialization. There would be no
default. Those encoding the content would choose either the "payload" or
"verbatim" member name.
This does not avoid the problem of there being two different ways to do the
same thing in the standard, with the interoperability problems that can result.
I am still not advocating that we support two ways of representing payloads.
But if the working group does decide that it's important to do so, I think that
this would be a credible approach for doing so. I think it would accomplish
what Jim is after here.
Thoughts?
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Dick
Hardt
Sent: Friday, June 28, 2013 4:04 PM
To: Richard Barnes
Cc: Jim Schaad; n-sakimura; Mike Jones; [email protected];
[email protected]
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded
Hi Richard, that helps.
Our you looking at a way of effectively signing a JSON payload? A complete,
real world example would help alot.
On Fri, Jun 28, 2013 at 3:57 PM, Richard Barnes
<[email protected]<mailto:[email protected]>> wrote:
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
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Jun 27, 2013 at 3:24 PM, Richard Barnes
<[email protected]<mailto:[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
