[Wg-uma] Requirements for pre-authn and/or pre-authz of Requesters?
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
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
(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
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?
> On Oct 19, 2009, at 19:46 PM, Eve Maler wrote:
>> In reviewing the meeting notes from last time:
>> ...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:
>> 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
>> do with a set of authorizations for access (vs. more selective one-
>> 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
>> If we can identify a solid real-world scenario here, then I suspect
>> can untangle if we have a new requirement here. As stated in the
>> "So do we have a requirement to pre-authorize access before the
>> Requester ever hits a Host? Or is it a requirement to pre-
>> 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
>> 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 Maler
>> eve at xmlgrrl.com
>> Wg-uma mailing list
>> Wg-uma at kantarainitiative.org
> 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]
> [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 at xmlgrrl.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Wg-uma