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