On Fri, Aug 24, 2012 at 12:17 AM, Justin Richer <[email protected]> wrote:
> I'd like to pose the question of what constitutes "a bit of extra > overhead". Making the overhead mandatory to support in the core can lead to > developer friction for the majority cases. > > This reminds me of the discussion on the OAuth list about returning > multiple tokens. Sometimes, yes, you want to return multiple access tokens. > Usually it's just one. We could have made the return value an array instead > of a string, but then you'd force every client to pull out > "access_token[0]" instead of just "access_token", and that's an annoyance > for the non-rare case. In the end, the group decided on supporting the > simple case in the core and letting an extension define the multi-token > format. That extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the standardization > question. > Actually, we decided to do it as an extension, called OpenID Connect. Userinfo endpoint actually returns multiple tokens. > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for different > use case, such as the JWS-JSON format that Mike's proposed or the multi-dot > format proposed below. I would argue that they're fundamentally different > kinds of objects and that conflating their use cases by forcing the > overhead is a big mistake. > +1 Note: I have a multi-signature use case that I have to solve, but I believe for the adoption purpose, we should be focused on the main use cases. > > -- Justin > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Here is my view: the muliple recipient case is a rare case. Having a bit > of extra overhead for rare cases is IMHO acceptable to keep the core spec > simpler. > > hannes > > Sent from my Windows Phone > ------------------------------ > From: ext Richard L. Barnes > Sent: 8/18/2012 12:58 AM > To: [email protected] > Subject: [jose] Splitting headers > > Hey all, > > At IETF 84, I suggested that we take another look at what header > information gets integrity-protected and what doesn't. The main issue > being that in multiple-recipient or multiple-signer scenarios, there's > unnecessary duplication of data if recipient- or signer-specific > information is in the integrity-protected header. > > Following some on what Bob Wyman proposed this afternoon, I would like to > propose that we split the set of header fields into some logical groupings: > 1. Top-level fields that require integrity protection (e.g., cty or a > digest algorithm parameter) > 2. Top-level fields that do not require integrity protection (e.g., x5c) > 3. Fields that are specific to a signer (e.g., jwk) > 4. Fields that are specific to a recipient (e.g., epk) > > In this taxonomy, only fields of type (1) need to be base64-encoded for to > preserve their serialization, and fields of type (3) and (4) could be > gathered together into the moral equivalent of SignerInfo and RecipientInfo > objects. All this makes the JSON serialization a lot cleaner, for example: > > { > "type": "S", > "header": "[base64-type1]", > "params": { /* type2 */ }, > "content": "[base64-content]", > "signers": [ > { /* type3 */ } > ] > } > > You can also imagine a reasonable compact serialization, something like: > > S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. > ... > > That encoding even has the benefit that the multi-signer case doesn't add > any overhead over the single-signer case, except for maybe a couple of "." > characters. (Obviously, you would want some structure on how the signer > info gets serialized, but that's another level of detail down. You could > imagine something like "[signer-header].[public-key].[signature-value]".) > > The additional structure might seem like it's more work to parse, but I > don't think it's really that bad. Given a parsed JOSE object "obj": > 1. Decode obj.header and add its fields to obj.params > 2. Look through "signers" / "recipients" to find one we understand > 3. Verify / decrypt content using signer/recipient info and parameters > > There are several details to be worked out -- most critically, which > fields go in which groupings -- but I thought I would throw out the general > idea for comment before diving into the details. > > Cheers, > --Richard > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing [email protected]https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
