...
Submitted by: Eve Maler
Actors
- User Authorizing user Alice, who chooses to set their her current location through an applicationvarious applications
- Authorization Manager that orchestrates which location applications can write to and read from other applications
- Applications that are Hosts of location information (some of which are also Requesters)
- Applications that are Requesters of location information (some of which are also Hosts)
...
Today's location services such as FireEagle, BrightKite, and Dopplr let you Alice set your her location within any one of several applications, and then use OAuth-enabled connections to propagate that information through other such services. Since location information can be privacy-sensitive, and since people can Alice can end up "chaining" services this way quite easily, with a thicket of pairwise connections, it's especially important valuable for a person her 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 through her authorization manager of CopMonkey about who's allowed to do what and , so she can change permissions in a coordinated way.
Note: This scenario is not exploring anything other than person-to-self sharing. How Alice exposes her location to other people and companies should be the subject of a different scenario, as warranted.
Dimensions
Nature of protected resource | API endpoint. For example, see the FireEagle developer documentation. The resource being protected is a single endpoint URL, with different options and parameters possible for using it. The possible scopes in today's location services tend to include (a) whether the requesting app (client) can write the user's location, and (b) to what degree the client can read the user's location. For example, see the FireEagle scope permissions documentation; the location-reading options include: no read access, as precise as possible, postal code level, neighborhood level, town level, regional level, state level, and country level. |
Sharing models | Current OAuth-protected usage of location services such as FireEagle and BrightKite assumes a person-to-self sharing model, where Alice has login accounts at the various host and requester apps, and wants to instruct them to share her location among themselves on her own behalf; an UMA-enabled version of this would allow her to control such sharing centrally at her AM. |
Nature of policies and claims | For person-to-self sharing, a typical policy might require the requesting party to be able to authenticate as Alice directly at the AM (that is, dictating a particular Step 2 web-server flow that uses normal OAuth user authentication), or might require a claim that it is an authenticated Alice asking for forge the connection. Further, a policy might set (unilateral) boundaries on which scopes can be accessed. |
Cardinality | This scenario is 1:1. There is no need to aggregate multiple resources from multiple hosts, for example. |
Colocation | The same requester app might both read and write location data (by using different methods with the same API endpoint), which allows a requester app it to write data to a host while still technically remaining a request requester (think "requester of API access"). With today's OAuth-enabled location services, the location services also seem to be act relatively "peer"-ish, in that they each have application galleries that have each done the necessary integration to support any one of them serving as an initial host with the others being requesters. So it could be said that the same app might be a host for some users and a requester for others, and/or might be set up as both a host and a requester for the same user's location; however, the latter may be very confusing given current OAuth realities. |
Host-AM relationship | Today's OAuth-enabled apps require static introduction and configuration, but the light weight and low security of these Web 2.0 services suggest that dynamic introduction is a possibility as long as the location API is well-known/standardized. |
Protected resource discovery | Today's OAuth-enabled apps advertise this location in the process of static introduction and configuration, but with a well-known/standardized location API, it seems possible that a location service host could advertise its endpoint through dynamic means such hostmeta/XRD. |
...
Below is a screenshot showing that FireEagle and Dopplr 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.
Use Case: Alice Sets Up Access Authorization Between Two Location Services
Alice currently uses the Dopplr service to record her upcoming trips, and likes using FireEagle to set her current location as she moves around throughout her day. She wants to get Dopplr to talk to FireEagle to tell it automatically when her location changes as a result of the start or end of a trip.
Preconditions:
- Alice has an account at the CopMonkey AM.
- Alice has an account at Dopplr.
- Alice has an account at FireEagle.
- Dopplr and FireEagle are UMA-enabled and use/advertise a standard location API but have not met before.
Steps:
- Alice introduces FireEagle to CopMonkey to protect access to FireEagle.
- Alice sets a default policy at CopMonkey that says requesting parties can set locations and can read locations at the city level.
- @@TBS
Use Case: Alice Adds a Third Location Service
@@TBS