Page Comparison

...

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 connected location services and indeed for all such services on the web that she chooses to use for hosting any data or content.

...

Assumptions and Preconditions

This scenario assumes that Alice has an account at each of AM, H, R1, and R2. These accounts might or might not be driven off of federated login, for example, Alice might log in to HotLocale through Google and RoadWarrior through Facebook; this is immaterial to the scenario.

This scenario assumes that AM, H, R1, and R2 are all UMA-enabled but have otherwise not met before. (Simplified circumstances that assume prior introduction are described in their turn below.)

This scenario assumes that H uses a hypothetical standard location API that R1 and R2 are configured to understand, and that H exposes an API through URLs that differ per user in some fashion (e.g., through a URL query parameter or through a part of the URL path).

Use Case 1: Alice Sets Up

...

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:

1. Alice introduces FireEagle to CopMonkey to protect access to FireEagle.
2. Alice sets a default policy at CopMonkey that says requesting parties can set locations and can read locations at the city level.
3. @@TBS

...

AM Protection Over Location Information at HotLocale

This flow can be embedded in other flows, or can be standalone.

1. H asks Alice to choose an AM to protect her location information in H
2. Alice tells H her preferred AM
3. H discovers how to get started connecting to the AM
4. Alice is redirected to AM to log in as Alice-on-AM, consent to protection, and choose a policy that applies to H's endpoint for her
   • The policy indicates that the requesting party must accept her chosen scope of access, which is "write, read-city"
   • The policy indicates that the requesting party must be able to log in at the AM synchronously as Alice-on-AM and consent
   • The policy does not otherwise discriminate against particular Requester apps
5. Alice is redirected back to H to continue what she was doing before

Use Case 2: Alice Shares HotLocale Location Access with RovingAround

1. Alice visits H and logs in as Alice-on-H
2. Alice decides to share access to her location information in H with R1 (if UC1 has not been done, it is done at this time)
3. Alice asks H to give her a "share" URL to use
4. Alice visits R1 and logs in as Alice-on-R1
5. Alice gives R1 the "share" URL from H and asks it to set up access to her location information there
6. R1 attempts to access the URL and discovers H uses a location API that R1 understands
7. R1 gets redirected to the AM as unauthorized
8. The AM tells R1 it needs to provide a claim acknowledging the offered scope
9. R1 sends the claim
10. The AM tells R1 it needs to redirect its user (Alice) to the AM to authenticate (add this as a special indicator/claim request to the protocol?)
11. R1 redirects Alice to the AM to authenticate and consent
12. The AM concludes that Alice authenticated correctly as Alice-on-AM
13. The AM issues an access token to R1 for location information access of the offered/accepted scope and redirects Alice back

Alice Shares HotLocale Location Access with RoadWarrior

@@TBS