WSRP Security subgroup minutes 7/10

Attendees: Mark Cassidy, Rich Thompson, Alejandro Abdelnur, Dave Clegg, Yossi Tamari, Olin Atkinson

1. User profile

a) Discussion around what standard profile elements should be adopted: it was suggested that we look at Liberty, Passport, Nortel LDAP for reuse. Alejandro to provide a pointer to the latter documentation; MarkC to review and make a recommendation.

Followup: Alejandro later reported that the LDAP definition is not part of any standards effort but rather was a joint initiative between Sun and Nortel. A new revision is due out shortly and Alejandro would make provide to the subgroup when available.

Followup: A summary of user data elements from various standards is included with these minutes. P3P defines a standard set of user data that looks to be the best fit for WSRP.

Once a standard set of profile attributes is defined, corresponding metadata needs to be defined to allow a producer to describe whether it wants the consumer to send user profile data, and which profile elements it wants the consumer to furnish.

b) Discussion around user profile data privacy issues: When a producer declares via metadata that a consumer furnish a set of user profile data, does that imply that secure transport must be used? Conclusion was that WSRP won’t require that secure transport be used whenever user profile data is being transferred. However, secure transport would be strongly recommended when significant elements or amounts of user profile data are requested by the producer. Ultimately, the consumer administrator can make the decision whether or not to use producers that don’t support secure transport based on the amounts and elements of profile data being requested.

c) Discussion around how user profile data passing fits into the protocol: several possibilities were briefly discussed:

- Producer makes a callback to consumer to get the user profile; this was rejected as highly undesirable since the protocol currently has no requirements for consumers to implement request handling from producers.

- Consumer passes profile with each request as a sort of transparent state; this approach could significantly increase the amount of data being transferred with each request depending on the size of the profile.

- Consumer passes profile once per session(? My notes were unclear on the specifics here?)

It was decided to defer further discussion until we had a better sense of how large user profile data objects were going to be.

d) P3P implications on WSRP: Mark took an action to review P3P in more detail to determine how WSRP fits with P3P.

Followup: P3P focuses mainly on a mechanism for content provider to create policies that describe how any personal data that is transferred during a content request will be used. It requires that user agents be simply able to display the policy to end-users. In a WSRP environment, a producer’s role would be one of a creator of P3P policies, and the consumer’s role would be one of displaying the producer’s P3P policies. The specification does not require user agents to support user privacy preferences(though that could be considered a logical extension) nor to protect those preferences in any way.

2. Roles

a) Standard role definitions: Discussion around the need for an abstract definition of what each of the standard roles mean. It was agreed that the concrete behavior implemented for each standard role the decision of each individual producer. An abstract definition needs to be provided with the standard to provide general guidance for the use of standard roles. Current proposal for standard roles are:

o administrator

o user

o page designer

o anonymous(new addition)

MarkC will re-post request for what roles are implemented in existing portal implementations to see if there are any other common roles that we should consider for adding to the standard.

b) Producer documentation of role-enabled behavior: the need for a description of the producer behavior associated with each producer-supported role(whether implementing support for standard or custom roles) was discussed. It was agreed that a description was important for the purposes of allowing an administrator to review this description and decide how to map portal users/roles to the producer’s defined roles. The description serves as documentation and is not intended to be of a structured form that can be acted on programmatically.

c) Role scoping: discussion around whether roles should be considered part of a user profile and what their scoping is. A scenario was described where a user’s role needs to be scoped to a specific entity. Consider the case of a calendar portlet: one entity of this type could be used for a personal calendar, where a user would have an ‘administrator’ type of role for this instance with ability to edit it’s data, where another entity of this type may represent a group calendar and the same user would have a less permissive role. This scenario should be possible in WSRP; call ended before we completed this discussion.