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

Eve Maler eve at xmlgrrl.com
Wed Aug 26 17:34:10 PDT 2009


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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.png
Type: image/png
Size: 55688 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-uma_kantarainitiative.org/attachments/20090826/8b75fd9a/attachment-0001.png>
-------------- next part --------------



Add a note to #Issue: Policies Specific to the Web Resource Type

Related to: Controlling Two-Way Sharing of Location Information (along  
with other scenarios)

(replace the language about the Photo Set scenario with this:) In the  
Controlling Two-Way Sharing of Location Information scenario, note  
that FireEagle allows a user to share location only at the city level,  
and this level happens to be chosen for the connection that authorizes  
Dopplr to read the FireEagle location (a different level can be chosen  
for each application that reads location from FireEagle).  As it  
happens, Dopplr does not offer the same policy capability.  Without  
having to teach UMA generically about all the possible policy options  
specific to all the kinds of information in the world, is it possible  
for each SP to teach each AM about the policy options it offers, in  
some way that lets the the relationship manager application  
surrounding the AM present user interface options to see and select  
these policies?  Seeing may have less protocol impact than selecting,  
and seems to be a minimum value-add if the goal is to allow OAuth  
users to get a global view.


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


More information about the Wg-uma mailing list