We have something similar as well... 2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov <[email protected]>:
> Arrays would be good. Perhaps even bit fields? > > We recently had a use case where we had to constrain the size of JWTs > and we successfully compressed an array of various constant claims into > a base64 encoded bit field, giving us significant space saving. > > Vladimir > > On 6.03.2015 21:43, Mike Jones wrote: > > Thanks for writing this, Joe. I know that people from the IoT and other > communities are already itching for a CBOR JOSE encoding and we'll do > everyone a service by providing one in a timely fashion. > > > > I think your proposal to set a high, well-understood and agreed upon bar > for any changes to the decisions made in JOSE is the key to having this > complete in a reasonable period of time. In my view, if we open most > decisions to be re-debated, our timeline is far more likely to look like > the JOSE timeline (in which we had the WOES BoF in July 2011 and are only > nearing having RFCs now over 3.5 years later) than the quick turnaround > achievable by building on past work that I think we would all like. > > > > Getting down to specifics, looking at the two COSE submissions to date, > https://tools.ietf.org/html/draft-bormann-jose-cose-00 and > http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's > submission is more effective at leveraging our existing decisions than > Jim's does so I'd personally want to use that as a starting point, but > there are some things I find valuable in Jim's draft as well. For > instance, I think that we should consider using arrays rather than maps at > the top level, as Jim suggests, as it may keep the code simpler and the > representations more compact. I'll note that this is actually parallel to > the JOSE Compact Serializations, which used data structures with fixed > numbers of elements in fixed positions at the top level, rather than JSON > objects, as was done in the JSON Serializations. > > > > I'll also add that I personally think we should only define one > serialization for the CBOR encoding. I would justify this departure from > JOSE as being in the name of "keeping simple things simple" - something I > think should also be part of our criteria when making our decisions. (If > people do need a URL-safe representation of a COSE object, it would be fine > for them to base64url encode the whole thing, for transmission purposes - a > suggestion that Joe made to me in person in Honolulu.) > > > > Anyway, I'm glad to see this discussion and look forward to us hopefully > completing a COSE standard within a year from now! > > > > -- Mike > > > > -----Original Message----- > > From: jose [mailto:[email protected]] On Behalf Of Joe Hildebrand > (jhildebr) > > Sent: Friday, March 06, 2015 11:19 AM > > To: [email protected] > > Subject: [jose] COSE: what would change? > > > > In talking with several folks about COSE, it appears that there are > differing views on how much to change in the JOSE/COSE translation. I > would like to explore the points of agreement and disagreement a little. > > > > > > It seems like most people agree that maintaining signature compatibility > is a non-goal; I agree that is the only way for us to have a chance at > success. > > > > > > I think we're also likely to get agreement that we should do our best to > use CBOR idioms in COSE (such as mixed-type keys for maps) once they are > explained to the group in enough detail for everyone to understand the > proposals. > > > > Finally, I think one of the reasons people are interested in COSE is a > chance to optimize for a different set of use cases than we had for JOSE. > > > > > > The main source of disagreement seems to be what we would change in COSE > of the things some might have wanted to done differently in JOSE. I'm > sympathetic to both the group that wants to crank something out quickly > without re-litigating the past, as well as to the group that wants to > re-optimize as many things as possible given the removal of the pressure of > existing codebases that we had with JOSE. > > > > > > An approach that might work for this would be to set a bar for changes > along the lines of "significant improvement in security, performance (wire > size, code size, CPU, power, etc.), or deployability" would be required to > justify a change. To see if that approach would work, it would be nice to > see a list of things that folks would want to change, and to get early > agreement on a couple of those changes as being above the bar that we set, > so that we have some precedent to reason from. > > > > > > To that end, I propose that those that want changes produce a list, > perhaps annotated with whether the change is seen as imperative or merely > nice-to-have. The folks that want a quick outcome would then select > several changes they see as being definitely above the line. My hope is > that this exercise would build trust that we all want something similar: a > high quality protocol standardized in as short a time as possible. > > > > > > -- > Vladimir Dzhuvinov :: [email protected] > > _______________________________________________ > 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
