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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

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


Subject: 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.


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