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
