Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Scenario: Controlling Two-Way Sharing of Location Information (Pending)

Submitted by: Eve Maler

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)

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.

  • No labels