OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

I agree with Yossi that these questions really need to be addressed by the
interfaces subcommittee and that they are essential for much of the
security work to proceed.

As to the points raised:
From the portlet point of view, it is important that there be a standard
means by which the set of parameters it uses be published to the portals
consuming it (including which are required). Some of the values for these
parameters may be stored persistently by the portlet while others must be
supplied by the portal. The portal may implement any number of means by
which these parameters are acquired and scoped relative to the portlets on
a page, but I think it is important that the means by which they are passed
to the portlet be directly carried by the protocol. The primary reason for
this is that the portal can not reasonably known whether the portlet will
have connectivity to an indirect source for these values.

We have discussed scenarios both where it is appropriate for most of the
parameter's values to be stored at the portlet and where for simple
portlets most (all?) parameters must be supplied by the portal. In some of
the WSIA discussions the question has been raised as to whether the
Producer (portlet) is even required to be stateful (ie remember the
parameters between invocations).

My take from a security point of view is that the values for the portlet's
parameters need to be transferred to it at some point in the interaction
between the portal and portlet. The specification/negotiation of the
security involved in that transfer (rather than the details of when or
what) should be the focus of this subcommittee.

                      "Cassidy, Mark"                                                                            
                      <mcassidy@Netegri        To:       "'wsrp@lists.oasis-open.org'"                           
                      ty.com>                   <wsrp@lists.oasis-open.org>                                      
                      04/30/2002 12:51         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
> be shared by other portlets or used for other functions within the
> 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
> 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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC