[wsrp-security] [wsrp][security] Agenda for 8/21 telecon

["Cassidy, Mark" <mcassidy@Netegrity.com>]

i have only one agenda item for this week's call, which is to review the
earlier access control decisions made by the subcommittee in light of a
thread last week on this subject.  To  summarize  past discussions, we
concluded that:

- access control to WSRP operations exposed by a producer service is managed
by the consumer.  THis was characterized at the time as a declarative form
of access control.  This has  no  impact  on the protocol or metadata.
- access control implemented programatically within the logic of a specific
operation  such as getMarkup() would be supported for producers via the use
of roles.  Producers that implement such behavior must  declare the roles
they support in their service description, and provide some form of
documentation on what that  behavior is so that a consumer administrator can
map portal users appropriately to the  producer's roles.

The current version of the spec has a userID string defined as an optional
element of the ConsumerContext.   The  use of this ID is primarily to
provide  a reference to the user's profile data.  In the last call we
decided that  the protocol  would be structured to include  the profile
data with each request; with this approach, the userID is not  needed to
reference  the profile.  We did, however, decide to allow for an
optimization where a consumer would only need to send the profile data once
per session, in which case the reference *is* needed.  

Excerpt from my notes for last telecon(minutes  still to  come...)
1.  Producer will have metadata that describes which profile elements it
wants to receive
2.  Consumer will send those elements on each request
3.  As an optimization, Producer may indicate in its metadata that it is
capable of maintaining profile data over the course of a private session and
prefers not to get profile on each request.  In this situation, the Consumer
MAY choose to not send profile with each request, but only once at the
beginning of the session.  If the profile data changes during the session,
the Consumer sends the profile data again on the next request after the
change.


Questions for discussion:
- Given that a userID string will be  present  in the protocol, is it
appropriate to use it for access control  purposes?
- The userID string is not standardized in any way,  i.e. such that a user
would  be identifiable by the producer regardless of which consumer the user
is connected  to.    We have not made this a requirement to date; is there
any need to?
- In my quick review of the .4 version of the spec, I did not see where
roles are passed as  part of any of various  context data other than for
getting  service descriptions.   Where in the  protocol does a  consumer
assert the role(s) for the current user?  

Call logistics:
Time:  8:00 a.m. PST(11:00 a.m. EST, 5:00 p.m. CET)
Reservationless-Plus Toll Free Dial-In Number: 877.450.3529
Reservationless-Plus International Dial-In Number: +1.706.679.6653
Conference Code: 4254674195