Re: [wsrp-wsia] [wsrp][intefaces] Use case for user filteredgetDescription()

[Rex Brooks <rexb@starbourne.com>]

This somewhat depends on whether the user wants the allow the 
Consumer to have that information. I think the Consumer first has to 
have permission from the end user explicitly. The end user may have a 
contract with the Producer that she does not want to allow the 
Consumer to know about.

Assuming such permission, then it probably belongs to the user 
profile. How and when that information is accessed is still somewhat 
up in the air. I expect that this question will arise more once we 
begin to get feedback from actual practice. I suspect that there will 
need to be clearly visible disclaimers on Portal pages that make 
these permissions clear, at least for the initial few sessions 
between the end user and specfic Portals/WebServices. It hasn't been 
clearly written into the protcol yet, and I am not sure that we 
should attempt to deal with it yet. Partially it is the domain of 
security in authentications and partially it is the domain of 
practice--what works scalably with the least disruption yet fulfills 
the legal requirements--and of course, the legal requirements will 
evolve.

I don't think we should attempt to specify this in this version. I 
think we should let practice inform us of what we ought to do.

Ciao,
Rex

At 4:00 PM -0700 8/8/02, Michael Freedman wrote:
>During today's conference call I asked the question "Do we care about
>allowing the consumer to ask get me the description of all the entities
>that this user has access to?" I indicated our Portal has such a
>capability but wasn't sure if/how its used. After a little discussion we
>tabled the question pending having me report back with a use case (if
>any).  This is our use case:
>      In our portal when a user displays the portlet repository (toolbox)
>she is only shown those portlets she has access to.  Though the bulk of
>this authorization is controlled via the Portal's authorization
>mechanisms we do provide a hook to the portlets authorization mechanism
>so it has an opportunity to decide.  (i.e. only users in a given portlet
>role can add this to portlet to a page).
>
>Our requirement seems to be express in some way via the protocol a way
>to ask the question can this user access this portlet?  For efficiency
>reasons it makes sense to expand this to what portlets can this user
>access?  In our proprietary portlet protocol we chose to overload
>getDescription to accomplish this.  Our getDescription takes an optional
>user which when present means only return me the information about those
>portlets this user can see.
>
>What we now need to answer are:
>      a) is this a valid and useful usage scenario we should support in
>the protocol?
>      b) if so, how should we support it?  getDescription overload?  Or
>should we have an isRunnable() type call (expecting of course these and
>other calls will ultimately be expanded to be [bulk] array based for
>efficiency?
>        -Mike-
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com