wsrp-interop message

Subject: Re: [wsrp-interop] guest/anonymous user access revisited

From: Richard Jacob <richard.jacob@de.ibm.com>
To: Michael Freedman <Michael.Freedman@oracle.com>
Date: Tue, 15 Jun 2004 11:27:35 +0200

my comments to the points below:

1. agreed
2. agreed, we've choosen the userContextKey for that purpose
3. why only to wsrp:minimal? couldn't the producer also define a guest user
catgegory "guest" and expose it in its service description. In that case
the consumer could map his guest categories to the producer's guest
category?
Isn't it just a special case that we assume that a guest is such a special
thing that it could only be assigned a "low" category like wsrp:minimal?
(This also prereqs the producer to declare wsrp:minimal as supported).
Can't the producer also do some kind of implicit internal) mapping if it
sees a guest user, espacially when we talk about case 1. This is what we
mandate in the spec.
4. OK, could be a use case. But what would be the userContext then? null or
userContextKey=wsrp:minimal + userCategory=null. If I understood your
intent in 2. correctly, then the latter option would be appropriate, or?

I think in general we agree and there are only nuances in the
interpretation.
To express a guest user where the consumer doesn't care about assigning a
category we're perfectly done with 1.
If a consumer want to assign a category to an end user we need
userContextKey=wsrp:minimal + category.
I really don't see why we limit this to just wsrp:minimal. This prereqs the
producer to a) support it and b) to have the same interpretation of it. But
producers could also be free to have a special guest category (like you
proposed it for consumers) and would like consumers to assert it in that
case. Also it contradicts the first case.
On the producer side we have to deal with two kinds of guest users then.
If the consumer passes userContext = null then the producer should map it
to some category if it supports one (that's what we mandate in the spec) -
this category could be guest.
If the consumer passes userContext != null + userContextKey=wsrp:minimal,
etc. then the producer would be enforced to map this user to wsrp:minimal
although it might want it to be guest.
Therefor I wouldn't restrict the userCategory to just wsrp:minimal.
If this is the only allowed assertion then it would be redundant anyway?
userContextKey=wsrp:minimal means guest, if passed the producer could also
assume wsrp:minimal category in that case.

Mit freundlichen Gruessen / best regards,

Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com

Michael Freedman
<Michael.Freedman
@oracle.com> To
wsrp-interop@lists.oasis-open.org
06/04/2004 01:21 cc
AM
Subject
Re: [wsrp-interop] guest/anonymous
user access revisited

I managed to take a brief look at these materials and wonder if we ended up
at the following:

1. Passing null as the user context still exists and still means the
consumer doesn't know who the user is -- i.e. this is an
anonymous/guest user however representing it this way means the
consumer can't pass any user category information.
2. If a consumer supports "guest" categories they must use an
alternative way to represent the guest user. To do this they pass a
userContext of "wsrp:minimal"
3. Consumers can only map consumer categories that a guest is in to
wsrp:minimal. It can only do this if the producer actually says it
uses/cares about wsrp:minimal.
4. In an such a conducive environment the consumer needs a way to
communicate/distinguish between a guest that isn't mapped to
wsrp:minimal and a guest that is. I.e. the user of the consumer
might have decided that guest categories shouldn't be mapped to
anything in this producer [not "wsrp:minimal"] and hence wants to
communicate that its guests run with no user cateory [i.e. NOT
wsrp:minimal]
I.e. in the end we said wsrp:minimal is the only valid user category for a
guest user because such a beast is a special case and we had no way to
distinguish [allow a producer to declare] which user categories apply to
this special case vs the typical "all user case". However, once we said
there was a way to have a meaningful user category for a guest then we
needed a way to distinguish between a consumer that says its guest should
have that user category vs. the absence of that category.

If this makes sense/sounds right then I think what we have is still okay
and doesn't need changing -- we merely need to take our minutes and expand
it into real words describing motivations and explaning uses.
-Mike-

Richard Jacob wrote:

here is the link to our original decision captured in the minutes:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-interop/download.php/2925/20030717%20WSRP%20Interoperability%20Minutes.doc

This one has not found its way to the spec, and was planned to be
part of
the errata.
Currently this is a Interop SC convention communicated to the TC.

Please review the minutes, and my summary and let me know your
opinions.

Mit freundlichen Gruessen / best regards,

Richard

Jacob/Germany/IBM

@IBMDE
To

wsrp-interop@lists.oasis-open.org
06/03/2004 01:06
cc
PM

Subject
[wsrp-interop] guest/anonymous
user
access revisited

Hi all,

we had the discussion about guest/anonymous user conventions some
time ago.
I volunteered to pick this up again and search for the rationales
that led
to our convention.
First, here is a summary of why we felt we need to revisit this
issue:

1. Producers are not required to provide any categories in the
ServiceDescription.userCategoryDescriptions
2. Consumers are not allowed to specify any userCategory not defined
in the
Producer's ServiceDescription
1+2=3. If the Producer does not define any user category being
supported,
the convention we've choosen prevents the Consumer to specify an
anonymous
user simply because it would contradict either 2. or the convention
-> no
way out for the Consumer.

Personally, I don't remember why we argued that userCategory in the
userContext has to be wsrp:minimal, too.
I guess the argument here was that a guest user is considered a user
with
minimal category as defined in the spec and therefor it
would not be convienient to assert a higher degree category to a
guest
user.
But as said, what if the Producer does not define wsrp:minimal as
supported?
In the end the producer prevents guest user category assertions in
this
case -- which could be perfectly valid, this would be a kind of a
negotiation then?

If the contextKey is wsrp:minimal the Producer already knows that
it's a
guest user and can assert whatever category he likes for that user
(if he
supports any, otherwise the discussion is obsolet).
If the Consumer for instance sends wsrp:full in conjunction with
wsrp:minimal contextKey, the Producer should be free to ignore that
and
reset it to wsrp:minimal?

I finally found the thread (we moved it to the wsrp mailing list to
target
a larger audience) in July 2003.
I found no real rationale for having a must for both: userContextKey
and
userCategory=wsrp:minimal.
The only indications I found were that we maybe wanted to express
that
guest users fit in exactly this one category (then why do we want to
assert one?)

However as I wrote in my summary, the producer can always interpret
the
userContextKey=wsrp:minimal as a guest and therefor ignore any
categoryAssertions from the Consumer and choose wsrp:minimal (or any
other
he uses for such a group of users).
The initial intent comming from Mike was to actually ASSERT a
category to
such a user class, therefore we defined our dummy userContextKey.
From todays point of view we actually PREVENTED that any other
category can
be asserted to this user set!
Mike, I wonder why you didn't stand up :-)

Atul also raised the question, whether a userContext=null couldn't
also
mean this guest user?
In that case we loose the initial intent to assert categories to
guest
users.

So I see the following flaws currently and the following options:

1. we need to get rid of the MUST of userCategory=wsrp:minimal in
that
case.Otherwise it doesn't make any sense to assert any category, the
Producer could always make a default assertion to wsrp:minial or any
other
category if he sees userContextKey=wsrp:minimal
2. user userContextKey=wsrp:minimal for guest user's and allow the
consumer
to assert any category for these users (which the producer declared
as
supported) -- it's another question if the producer follows this
assertion.
3. userContext=null as defined currently: no assumptions about the
user, no
(predefined) category assertions
4. userContext=null equals anonymous user?: producer can treat the
user as
he would treat it in 2. but assert a default "guest" category of its
choice
(I think consumer would do something anyways and is already covered).

My opinion is:
we should do 1., 2. and 3..

Mit freundlichen Gruessen / best regards,

To unsubscribe from this mailing list (and be removed from the roster
of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php

To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
.

Follow-Ups:
- Re: [wsrp-interop] guest/anonymous user access revisited
  - From: Atul Batra <atul.batra@Sun.COM>

References:
- Re: [wsrp-interop] guest/anonymous user access revisited
  - From: Michael Freedman <Michael.Freedman@oracle.com>