Agreed -----Original Message----- From: Dick Hardt [mailto:[email protected]] Sent: Tuesday, March 22, 2011 2:08 PM To: Mike Jones Cc: Joe Hildebrand; Paul Hoffman; [email protected] Subject: Re: [woes] Preparation for the WOES meeting
I'd add URL safe encoding as a goal. Alleviates mismatched encoding / decoding bugs. On 2011-03-22, at 11:23 AM, Mike Jones wrote: > Thanks, Paul and Joe, for helping frame the discussions. I thought I'd add > the perspective of those working on the JSON Web Token (JWT) format in the > way that Joe did for the JSMS format: > > Goals: > - minimized wire size - enabling use in space-constrained > environments, such as mobile browser query strings > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but a small set of standard algorithms defined > for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - easy discoverability by new implementers (view source approach) > - very limited extensibility > > Anticipated extensions: > - multiple signers on the same plaintext > > Non-Goals: > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON, > BSON) > - minimized memory > - minimized CPU > - multiple recipients for a single encrypted payload > - self-describing type structure for data structures > > The primary difference is that using a compact representation is a key goal > of the JWT spec. > > Looking forward to talking with many of you next week! > > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Joe Hildebrand > Sent: Saturday, March 19, 2011 1:43 PM > To: Paul Hoffman; [email protected] > Subject: Re: [woes] Preparation for the WOES meeting > > Paul, this is a very helpful starting point - thanks. > > From my perspective (ekr can chime in on his own) there is nothing about the > JSMS format that we need to "win". There are some things I'd like to to see > in the eventual format(s): > > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but *one* (or as close to one as possible) > algorithm defined for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - multiple recipients for a single encrypted payload > - easy discoverability by new implementers (view source approach) > - very limited extensibility > > Things that I don't see as priorities: > - multiple signers on the same plaintext (one signature can wrap > another) > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON, > BSON) > - mimimized wire size > - minimized memory > - minimized CPU > > On 3/18/11 7:08 PM, "Paul Hoffman" <[email protected]> wrote: > >> Greetings. We would like to set the tone for the WOES >> meeting-that-is-not-a-BoF that will happen on Monday, March 28, in >> Prague. The meeting will be from 2000 to 2130 in the Karlin I room. >> Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this >> meeting, and in turn we have assured him that neither of us want to >> chair an eventual WG, if it is chartered. >> >> We believe that a reasonable schedule might be: >> >> 10 min introduction by Lucy and Paul >> 20 min discussion / presentation on draft-rescorla-jsms >> 20 min discussion / presentation on draft-jones-json-web-token >> 40 min discussion on what the rest of the community wants >> and how it wants to proceed >> >> For this meeting, we would like to talk almost exclusively about the >> format, not the many different places where such formatted objects >> might be used. This is based on an assumption that as long as the >> eventual format has just enough building blocks plus some well-scoped >> and well-designed extensibility, the discussion of where it can be >> used is actually better had in the respective WGs, not here. >> >> We note that the two proposed formats should probably be called "the >> first two proposed formats": it is possible that there are others. >> The group needs to decide over time whether the desired outcome is >> one format or more than one format; history in the IETF indicates that this >> will not be an easy decision. >> Another discussion topic is what kinds of documents are needed other >> than format documents: is a requirements document (and possibly other >> non-format >> documents) needed? >> >> We note that this is not a formal BoF, and we will not be the >> eventual leaders, so we are keeping this "agenda" informal as well. >> Please let us know what you think of this. >> >> -- Lucy Lynch and Paul Hoffman >> >> _______________________________________________ >> woes mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/woes > > -- > Joe Hildebrand > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
