[Wg-uma] Requirements for pre-authn and/or pre-authz of Requesters?

Eve Maler eve at xmlgrrl.com
Tue Oct 20 10:56:14 EDT 2009


These are exactly the right questions to ask. I'm not sure of the  
answers, because we need to get a clearer picture of the goals of the  
scenario.

I could see the service catalogue service (perhaps call it a discovery  
service?? :-) being hosted at a relationship manager app right  
alongside the user's AM, though it doesn't have to be. The next thing  
I'm still trying to figure out is, does this sort of app want to have  
any kind of authorization power for the services it catalogues? That  
seems to be what is suggested by the scenario as written, which may  
indeed require changes in our conception of UMA if we agree. And if a  
service approaches it as a Requester, exactly what sort of access is  
it reasonable to request of a set of Hosts that have been registered  
there?

(Does anyone who has worked on ID-WSF or the new ID-WSF Evo stuff want  
to weigh in on the use cases that motivated them, in addition to the  
XRD perspective?)

	Eve

On 20 Oct 2009, at 5:36 AM, Peter Davis wrote:

> I like this use case a lot... something i had always envisioned a  
> smarter, policy-aware XRD infrastructure could be when it grows up  
> (that is, my service catalogue).
>
> Isn't the 'Service Catalogue' just another service, which happens to  
> be under the (presumably) total control of the user?  If that is the  
> case, then would we not think:
>
> * Alice adds decides to add 'NewService' to her catalogue of  
> services, and clicks the 'add to my services' button...
> * "classical" UMA authZ dance proceeds, resulting in NewService  
> having an entry in said catalogue
> * the service catalogue provides an intuitive set of default  
> settings for services recently added (maybe alice provides an  
> initial paranoid default, and over time, she adds more access to her  
> other services to NewService as she gains confidence in them).
>
> So much of the above points to implementation, without the need to  
> add more to the working requirements of UMA....
>
> ... or perhaps I am not seeing something subtler here?
>
> =peterd
>
> On Oct 19, 2009, at 19:46 PM, Eve Maler wrote:
>
>> In reviewing the meeting notes from last time:
>>
>> http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2009-10-15
>>
>> ...I thought it might be a good idea to start an email thread on the
>> "mass authorization" idea represented by Christian's distributed-
>> services scenario, so we can be prepared to discuss it next time:
>>
>> http://kantarainitiative.org/confluence/display/uma/distributed_services_scenario
>>
>> The mockup screenshot here is particularly interesting, but I feel a
>> need to dig into it more to really understand.  What's an example of
>> "New Service"?  Does it represent another *person* in your life whom
>> you want to authorize to see your various activity streams, or just
>> another *service* that you yourself use?  If the latter, what would  
>> it
>> do with a set of authorizations for access (vs. more selective one- 
>> by-
>> one authorizations) if the API for each of the Hosts is wildly
>> different?  What do you as the Authorizing User gain by doing a mass
>> authorization -- or is this just for the efficiency/performance of  
>> the
>> Requester?
>>
>> If we can identify a solid real-world scenario here, then I suspect  
>> we
>> can untangle if we have a new requirement here.  As stated in the
>> minutes:
>>
>> "So do we have a requirement to pre-authorize access before the
>> Requester ever hits a Host? Or is it a requirement to pre- 
>> authenticate
>> particular Requesters (like the service called "New Service" in
>> Christian's wireframe diagram)?"
>>
>> (BTW, the revocation of access by a single Requester, which is
>> mentioned at the end of the scenario, is something we imagined pretty
>> early on.  I don't *think* we need to consider any changes to the
>> ProtectServe sketch to achieve it, because the user can go into their
>> AM anytime and tweak settings, resulting in authorization being  
>> denied
>> on subsequent access attempts.  Outside of the protocol, AM services
>> could compete on how granular their policy-setting apparatus is, e.g.
>> per Requester, per Host, per individual resource, per group of
>> Requesters, etc.)
>>
>> 	Eve
>>
>> Eve Maler
>> eve at xmlgrrl.com
>> http://www.xmlgrrl.com/blog
>> _______________________________________________
>> Wg-uma mailing list
>> Wg-uma at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
> Peter Davis: Neustar, Inc.
> Director & Distinguished Member of the Technical Staff
> 45980 Center Oak Plaza Sterling, VA 20166
> [T] +1 571 434 5516 [E] peter.davis at neustar.biz [W]
> http://www.neustar.biz/
>  [X] xri://@neustar*pdavis [X] xri://=peterd
> The information contained in this e-mail message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient
> you have received this e-mail message in error and any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately and delete the original message.
>


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20091020/b4736848/attachment-0001.html 


More information about the Wg-uma mailing list