[jose] Some requirements and non-requirements

[Matt Miller <[e-mail]>]

A number of us had a short discussion in the hall in Taipei not-too-long ago, and came up with some needs (and non-needs) that differ from the current proposals.  Some of this was stated in the meeting, some may not have been.  My explanation and requirements/non-requirements follow; I'll let the others send their own comments.

We (XMPP) have an asynchronous protocol that involves multiple hops (most often no more than 3), and have a need to protect this information end-to-end.  However, the end-points are not guaranteed to be singular; the protocol allows for a single account or bare JID to have multiple simultaneous resources involved.  It is possible that the sender will not know precisely which resource will ultimately receive a stanza, but it is possible that such a sender will know of all the possible recipients, and have asymmetric keys for each of these recipient end-points.  Since one of our stanza kinds is intended for conversations, it would be desired (but not absolutely necessary) to be able to reuse a session key across multiple discreet payloads.

Further, authenticity or integrity of the data is not always important.  For various reasons, there is assurance in the asserted identity of each entity.  That's not to say it's *never* important, but that there exists other factors that make it less important in a lot (I would say most) cases.

With all of that, we have the following requirements:

* Support multiple known recipients
* data needs to be standalone XML safe

And the following non-requirements:

* data need not always be signed
* data need not be URL safe
* data need not be tightly coupled/interleaved with the meta-data


- m&m

Matt Miller - <[e-mail]>
Collaboration Software Group - Cisco Systems, Inc.