RE: [wsrp][security] Agenda for 5/1 telecon: User Profile

["Tamari, Yossi" <yossi.tamari@sapportals.com>]

Hi mark,

I really think that these are issues that should be discussed by the
interfaces sub-committee (everyone). These are not security issues, even
though they certainly have a huge effect on the security requirements.
It seems to me that as the security sub committee should raise these
questions urgently in the interfaces discussions, since not solving them is
holding us back.

	Yossi.

-----Original Message-----
From: Cassidy, Mark [mailto:mcassidy@Netegrity.com]
Sent: Tuesday, April 30, 2002 7:51 PM
To: 'wsrp@lists.oasis-open.org'
Subject: [wsrp][security] Agenda for 5/1 telecon: User Profile



> I'd like to focus discussion in tomorrow's call on the issue of user
> profile.  There seems to be different ideas about what personalization
> means and how it relates to user profile.  
> 
> Take the runtime flow of a portlet computing the markup it returns to the
> portal:  the portlet requires a number of parameters to be defined in
> order to generate the markup it returns to the portal.  Some of these
> parameters may be explicitly associated with the portlet instance and
> stored with the persistent data for that instance.  Other parameters may
> be obtained from someplace else, such as user profile, where that data may
> be shared by other portlets or used for other functions within the portal.
> 
> 
> Another twist to this is that it is not uncommon for portals to support
> the notion of a portlet parameter value which is scoped to a group.  
> 
> The logic that drives assembling all the parameters needed by a portlet to
> generate it's markup needs to be clear.   
> 
> A couple questions to get some discussion going on the forum prior to the
> meeting:
> 
> 1.  Should a portlet instance be scoped to individual users, with all
> parameters fully specified, such that a given instance always returns the
> same markup?  Or should an instance represent a partial parameterization
> of a portlet service(one step more fully specified than the portlet
> template), where the remainder of user-specific parameter values needed
> are fetched at runtime from some source outside the portlet instance?
> Another scenario might be that *all* users' parameterizations would be
> maintained with the instance data; in this case, the runtime invocation
> would require both an instance handle and some type of user handle.  My
> own opinion on this is that each instance should correspond to a fully
> enumerated parameter set, where a unique instance handle would exist for
> each user's personalized configuration of the portlet.   
> 
> 2.  If not all the parameter values are stored with the instance, what
> mechanisms should be supported for assembling the full parameter set at
> runtime?  How is this divided between portal and portlet?  A user profile
> would logically fall under this mechanism. 
> 
> 
> I'm going to be offsite for the remainder of the day today and will be
> back on email later tonight to followup on any discussion around these
> points.
> 
> 
> Logistics:
> Time:  Wednesday, 5/1;  8:00 a.m. PST(11:00 a.m. EST, 6:00 p.m. CET)
> U.S. Phone:   877.450.3529
> International phone:  +1.706.679.6653 
> Conference Code: 4254672722
> 
> 
> 
> 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>