Skip to end of metadata
  • Created by Former user, last modified by Former user on Sept 22, 2010
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 3 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
  • Hosts (some of which are also Requesters)
  • Requesters (some of which are also Hosts)

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.

Dimensions:

  • Scope: This use case involves scope since each of the services (SP) that the user wishes to obtain services (data) may have different scoping rules.
  • Cardinality: This use case may have a non-zero cardinality since the user may use multiple Hosts who in-turn may be Requesters.
  • Nature of Host:  This use case allows for the scenario in which a Host becomes a Requester.
  • Person-to-self: This use-case may be implemented in such a way that if the Host#1 (selected by the User) acts as a Requester to a different Host#2, the Host#2 may explicitly require the User to authenticate and authorize in order to allow Host#1 to complete its tasks.
  • No labels