RE: [wsrp-wsia] [change request #7] User identity (authenticated) forpersonalization

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

User profiles are there exactly for personalization, so I don't understand your statement "I also don't quite understand why the option of user profiles for personalization was never considered.".

The committee considered moving UserCategories into the user profile, but there was a pretty wide agreement that UserCategory mapping would still have to remain a feature, so UserCategories can not be just a set of properties on the profile. The feeling was that considering this, we are more
comfortable with the current location of the UserCategories.
What's more, on a technical level, the profile is (relatively) static for the user and may be cached at the session level, while UserCategories may be different per user per portlet.

	Yossi.

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: Monday, January 20, 2003 9:56 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [change request #7] User identity
(authenticated) for personalization


Referring to page 49, lines 36-37, which reads

"A Portlet optionally declares the user categories it personalizes 
markup for in the PortletDescription structure described in section 
5.1.11. "

 From this statement, the fact that the producer MAY use user categories 
for personalization is not very clear to me. Somehow, the wording seems 
to combine user categories with personalization. From what I understand 
from the various emails that were exchanged about this issue, I'm under 
the impression that people wanted categories to be able to personalize.

At a more fundamental level, the word "personalization" bothers me. But 
I can live without a formal definition (from WSRP's perspective).

I also don't quite understand why the option of user profiles for 
personalization was never considered. That would actually make the spec 
more abstract (and avoid all role-related debates). Moreover, unlike the 
term "personalization", "user profile"s are extensible and have a formal 
meaning in WSRP (as also in JSR168).

What does the rest of the TC think about this?

Subbu

Tamari, Yossi wrote:
> I do not think the spec currently excludes any other implementation. It actually uses in this section only "MAY" and "optionally".
> The point is that any other implementation is NOT part of the WSRP spec, and must be separately agreed upon between the producer and the consumer, which is why I refer to it as an extension.
> 
> 	Yossi.
> 
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: Monday, January 20, 2003 8:14 PM
> To: wsrp-wsia@lists.oasis-open.org
> Subject: Re: [wsrp-wsia] [change request #7] User identity
> (authenticated) for personalization
> 
> 
> Tamari, Yossi wrote:
> 
>  > How would this sophisticated producer get the authentication and role
>  > information? Don't you actually mean a specific producer/consumer
>  > pair, that have (somehow) established a trusted way of passing user
>  > and roles? It is dangerous to rely on this user ID for
> 
> Yes. But I don't understand why it is dangerous to rely on user identity 
> for personalization. It depends on what is being personalized and how a 
> producer chose to implement it.
> 
>  > personalization rather than the userContextID, since we defined use
>  > cases where the consumer wants a group of people to share the same
>  > personalization (a team concept). The userConetxt allows for that,
> 
> Yes. But in some scenarios (e.g, corporate portals), user identity 
> and/or identity-derived information is more useful for personalization.
> 
>  > while using authenticated user ID instead would actually require
>  > impersonation of a non-existing user!!!
>  >
>  > The equivalent problem also arises for userCategories: The
>  > userCategories are for this specific portlet so they may not match
>  > the general user's role in the producer, and there is also no support
>  > in WSRP for exposing these roles and creating mapping (WS-Security
>  > may be the answer, but I don't think we will have portals from any
>  > two vendors that will can do this correctly currently). What you are
>  > really suggesting here is that it is allowed to use extensions to
>  > pass this information. I agree. But that is also true for other parts
> 
> I don't mean extensions. The consumer may use the same security 
> infrastructure that was used for authentication to propagate/assert this 
> information.
> 
> My concern is that, the current wording of the spec conspicuously 
> excludes other means of personalization (such as using eg., J2EE roles, 
> or some other form of role mapping or something else).
> 
> Subbu
> 
> 
> 
>  > of the protocol, and we don't explicitly state that.
>  >
>  > Yossi.
>  >
>  > -----Original Message----- From: Rich Thompson
>  > [mailto:richt2@us.ibm.com] Sent: Monday, January 20, 2003 6:03 PM To:
>  > wsrp-wsia@lists.oasis-open.org Subject: [wsrp-wsia] [change request
>  > #7] User identity (authenticated) for personalization
>  >
>  >
>  > Document: WSRP Spec v0.9 Section: 6.10 Page/Line: 48/36-42 Requested
>  > by: Subbu Allamaraju Old text: Proposed text: [addition]
>  > Sophisticated producers may completely ignore user categories and
>  > instead rely on authenticated user and/or consumer identity for 
> personalization of behavior and/or markup.
>  >
>  > Reasoning:
>  >
>  > Sophisticated producer-consumer implementations may choose to
>  > propagate authenticated end user security context using some
>  > (unspecified) security mechanism. With such a security mechanism in
>  > place, a producer may choose to use the authenticated principal and
>  > roles for personalization in place of userContextID and
>  > userCategories.
>  >
>  > I suggest that this section mention this possibility. This would also
>  >  address sophisticated implementations that rely only on
>  > authenticated user identity and roles for personalization.
>  >
>  >
>  >
>  > ---------------------------------------------------------------- To
>  > subscribe or unsubscribe from this elist use the subscription 
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>  >
>  > ---------------------------------------------------------------- To
>  > subscribe or unsubscribe from this elist use the subscription 
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>



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