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

[Peter Davis]

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.

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