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]> wrote: > > > > 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
