Design teams

[Edward Lewis <lewis@tislabs.com>]

First, I would like to set a target date of March 30 for the design teams
to submit to the mailing list a set of issues and opinions (so far) so the
WG can provide some feedback.  This isn't intended to be a deadline for the
design teams, but a midpoint check on progress.  (The "set of issues" can
be similar to what was put on screen yesterday, but this time in text.)

For the security team, there is one item that seems to need addressing.  We
need to identify the threats that the RRP will have to be defended against.
Traffic inspection, modification, etc. are documented means of attack.
What I have in mind are identification of ways that the RRP may be abused
(requesting unauthorized actions, leakage of contact data to spammers,
etc.).  I do think that we need a better understanding of the 'privacy'
issue before declaring it of scope of the protocol.  By identifying the
threats we can determine which "security" services are needed.

For the protocol and transport teams, I'd like there to be some addressing
of how the choice of transport will impact the protocol.  E.g., if one
transport layer offers a security service to the protocol and another
transport does not, how will the protocol know to adapt.

[1] - Regarding my comment about authorization vs. authentication.  IMHO,
Authorization is more germaine to the problem here because we want to know
if the client (whomever they are) is allowed to request an action.  Of
course, to make an authoriztion determination, you do need to perform some
authenication first.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.