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
