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

Maciej Machulak m.p.machulak at newcastle.ac.uk
Thu Aug 27 07:14:46 PDT 2009


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.)






More information about the Wg-uma mailing list