[Wg-uma] Proposed: Location scenario to replace Photo Set one

Eve Maler eve at xmlgrrl.com
Sat Aug 29 08:17:08 PDT 2009


A couple of thoughts on this (in advance of having really studied the  
latter half of your document -- I promise, I'm getting to it! :-):

On sets of resources:

A set of resources should ideally be handled as a resource itself; on  
one of the calls we briefly discussed the notion of using Atom as a  
sort of manifest for several resources, which might be hosted in  
multiple places, and I do like the notion of literally authorizing  
access to a "feed" of data.  But really, whatever manifest format that  
gets settled on will do.

For simplicity, let's say we're talking about the infamous photo set,  
which is composed of photos hosted at the *same* place.  Do people  
really move such things wholesale?  If they do, what does that  
operation look like today -- is it an export->import thing?

If there can is a URL that represents the whole set, then policies can  
hopefully be applied to it (and perhaps recursively to its members --  
another question, which largely lives in the UX world and not the  
protocol world).

On transferring policies:

I would love for the ecosystem to get so sophisticated that we need to  
optimize the process of re-applying complex policies to photos and  
sets when they are moved to a new host.  But my suspicion is that, for  
use cases involving real individuals acting on their own behalf (and  
not analogous back-office transactions), policies will have to be  
quite simple, with lots of defaulting going on, for anyone to pay  
serious attention to them.  So this could potentially be an area where  
we try not to preclude sophistication later, but don't put these  
design issues on the front burner.

	Eve

On 27 Aug 2009, at 7:14 AM, Maciej Machulak wrote:

> Hi,
>
> I just wanted to add something to the "Policies Specific to the Web  
> Resource Type" issue as introduced by Eve.
>
> I think it's an excellent approach to teach an Authorization Manager  
> about operations that are supported by a particular resource. When a  
> resource needs to be protected by such AM and is being introduced to  
> the AM then such operations could be presented to the AM by a  
> Service Provider. This would not restrict us to the common set of  
> operations used by truly RESTful Web Services (HTTP GET/POST/PUT/ 
> DELETE operations) but to use the exact operations as supported by  
> an application and in the form the application supports them (this  
> is also discussed in 2.8 and 2.9 scenarios in my previous use cases  
> document).
>
> What I would also like to raise is how to allow an Authorization  
> Manager control access to resources independently of the Service  
> Provider that hosts those resources. If a policy is applied to a  
> document hosted by one Web application that supports a certain set  
> of Web applications and I move this resource to a different Web  
> application, how can I reapply the same policy. This can be easy for  
> one resource (changing the realm) but how about a set of resources?  
> What if the new Web application supports a different set of  
> operations? Some of that is also discussed in my document (section  
> 2.9.4):
>
> "Reapplying an access control policy to a set of resources does not  
> differ
> much from applying a single policy to a resource hosted by a Web  
> application.
> Typically, when a user creates a resource on the Web and wants to  
> protect it
> then a Web application contacts a Security Provider so that either a  
> new access
> control policy can be composed or an already defined policy can be  
> applied.
> In a situation where a resource is transferred from one application  
> to another,
> the new application perceives such resource as newly created.  
> Therefore, this
> new Web application contacts a Security Provider as usual. It is a  
> Security
> Provider that detects that a policy for this resource has been  
> previously defined
> and applied. Therefore, this Security Provider proposes to reapply  
> the same
> policy to protect this particular resource.
> An important issue that needs to be resolved in the discussed use  
> case is
> the possibility of having different operations that are supported by  
> different
> applications for the same type of resources. An example of that is  
> when one
> application allows downloading, writing, deleting and shrinking a  
> picture while
> another application allows downloading, writing, deleting and  
> transforming pic-
> tures. When an application contacts a Security Provider it sends  
> information
> about a resource along with operations supported on this resource. A  
> Security
> Provider may detect that a policy has been already specified for  
> such resource
> and may propose such policy to be reapplied. However, a set of  
> operations de-
> scribed by a new Web application may differ from the set of  
> operations that are
> defined in a security policy. This can be either a subset of  
> original operations,
> a superset of those operations or a different set of operations.
> If a new Web application supports only a subset of operations that  
> were
> originally supported by the previous Web application, then rules for  
> those oper-
> ations that exist in an access control policy are simply removed. In  
> case a new
> application supports a superset of operations then all rules from an  
> access con-
> trol policy are retained. New rules for newly supported operations  
> can be easily
> added to the policy. In case the set of operations differs from the  
> operations
> as defined in an access control policy, a human intervention may be  
> required to
> map names of old operations to the names of new operations."
>
> Cheers,
> Maciej
> ________________________________________
> From: wg-uma-bounces at kantarainitiative.org [wg-uma- 
> bounces at kantarainitiative.org] On Behalf Of Eve Maler  
> [eve at xmlgrrl.com]
> Sent: 27 August 2009 01:34
> To: WG UMA
> Subject: [Wg-uma] Proposed: Location scenario to replace Photo Set one
>
> I took an action at last week's meeting to revise the Photo Set
> scenario based on our discussion.  We didn't have a conclusive answer
> about whether we should include the "multiple resources from multiple
> sources" aspect; I've decided not to include it, since my conversation
> with Iain earlier this week about VRM scenarios convinced me it will
> get covered elsewhere (in email from me, sometime before tomorrow!).
> So here is my proposed replacement.
>
> #Scenario: Controlling Two-Way Sharing of Location Information
>
> Distinctive aspects:
>
> • Potentially two-way service access. Think of it as a read-write
> operation, or an HTTP GET/POST/PUT/DELETE.
> • Not only inspired by OAuth's authorized interactions, but relies on
> integrating with OAuth-enabled services specifically (though not
> without UMA-related changes to OAuth endpoints).
> • Raises an issue (see more about this below) about the potential need
> for an AM to learn an SP's capabilities around operation-specific  
> policy
>
> Actors:
>
> • User
> • Authorization Manager
> • Service Providers (some of which are also Consumers)
> • Consumers (some of which are also Service Providers)
>
> Description:
>
> Today, many Web 2.0 services are beginning to offer users features
> that depend on connections with other third-party services, using
> OAuth to forge the connection. A classic example is sharing your
> whereabouts between services.  Since location information can be
> privacy-sensitive, and since people can end up "chaining" services
> this way, it's especially important for a person to know and control
> where this information is flowing to.
>
> In this scenario, a user of FireEagle, Dopplr, and BrightKite wants to
> connect them all up to be able to read *and* write her location to all
> of them, and she wants to get a global view of who's allowed to do
> what, and change permissions in a coordinated way.
>
> Below is a screenshot showing that FireEagle and Dopplr do have the
> capability today to have two-way location information flow.  Our user
> wants to be able to see this "combinatorily", for all location
> services and indeed for all such services on the web that she chooses
> to use for hosting any data or content.
>
> (I should probably add several use cases to this, that flesh out the
> various policy propositions highlighted in the issue text below, but
> let's discuss it on a call first.)


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




More information about the Wg-uma mailing list