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