...
- Authorizing user Alice, who chooses to set and share her current location through various applications that she accesses with a commercial off-the-shelf browser
- An application that serves as an Authorization Manager (AM) on Alice's behalf, orchestrating which location applications can write to and read from other applications
- A webWeb-based location application applications called HotLocale (HH1) and HipHappeningPlaces (H2) that is a Host are Hosts of a location resource information on Alice's behalf
- Web-based location applications called RovingAround (R1) and RoadWarrior (R2) that are Requesters of location information on Alice's behalf
...
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, HH1, H2, 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, H1, H2, 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 H1 and H2 use a hypothetical standard location API that R1 and R2 are configured to understand, and that H1 and H2 expose APIs 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:
- 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
...
AM Protection Over Location Information at HotLocale
This flow can be embedded in other flows, or can be standalone.
- H1 asks Alice to choose an AM to protect her location information in H1
- Alice tells H1 her preferred AM
- H1 discovers how to get started connecting to the AM
- Alice is redirected to AM to log in as Alice-on-AM, consent to protection, and choose a policy that applies to H1'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 (note that we don't currently have a way to do this; do we need to?)
- She labels the policy "location services policy" (outside the scope of the UMA protocol)
- Alice is redirected back to H1 to continue what she was doing before
The identical sequence can be done with HipHappeningPlaces (H2).
Use Case 2: Alice Shares HotLocale Location Access with RovingAround and RoadWarrior
- Alice visits H1 and logs in as Alice-on-H1
- Alice decides to share access to her location information in H1 with R1 (if use case #1 has not been done, it must be done at this time)
- Alice asks H1 to give her a "share" URL to use
- Alice visits R1 and logs in as Alice-on-R1
- Alice gives R1 the "share" URL from H1 and asks it to set up access to her location information there
- R1 attempts to access the URL and discovers H1 uses a location API that R1 understands
- H1 redirects R1 to the AM as unauthorized
- AM tells R1 it needs to provide a claim acknowledging the offered scope (need to standardize this claim request/response)
- R1 sends the claim to AM
- AM tells R1 it needs to redirect its user (Alice) to AM to authenticate (add this as a special indicator/claim request to the protocol?)
- R1 redirects Alice to AM to authenticate and consent
- AM concludes that Alice authenticated correctly as Alice-on-AM
- AM issues an access token to R1 for location information access of the offered/accepted scope and redirects Alice back
The identical sequence can be done with RoadWarrior (R2), except that once HotLocale is introduced to the AM, it never needs to be introduced again, so the optional embedded UC1 block isn't ever done again unless Alice wants to switch AMs.
Use Case 3: Alice Monitors and Controls Location Information Access from Her AM
To monitor access, Alice interacts with value-added functionality provided at the "data-sharing relationship manager" application that serves as her AM endpoint; that is, this use case does not involve standardized UMA protocol behavior. These interactions might include:
- Looking at a unified log for occasions when both RovingAround and RoadWarrior accessed HotLocale on her behalf, and what they did on those occasions
- Looking at a unified log for occasions when RovingAround accessed both HotLocale and Alice's calendar application (not part of this scenario) on her behalf
- Looking at a unified log for all hosts to whose resources she applied her "location services policy", including both HotLocale and HipHappeningPlaces
- Showing a graphical depiction of location host and requester access relationships and their types, if it is able to characterize hosts according to the APIs/resource types they expose
To control access, Alice may take various actions:
- If Alice discovers that her HotLocale account was hacked, she can go into her AM and revoke access to it from all requesters. If access tokens issued to requesters are sufficiently short-lived, the next time any of them seeks access by presenting a refresh token in order to get a new access token, they would be denied access. (would the OAuth 2.0 token revocation extension help here?)
- Alice may decide that she wants to limit access to include reading her location from HotLocale only, instead of reading and writing her location, because the previous situation was too confusing. She can change the "location services policy" to limit the scope list. If access tokens issued to requesters are sufficiently short-lived, the next time any of them seeks access by presenting a refresh token in order to get a new access token, they would be asked for a claim acknowledging the reduced scope and be issued a new access token.
Issues
- Scope claim: Need special claim request/response regarding some scope list being offered by the authorizing user, as imagined above?
- RESTful API: Do we really need the assumption that the protected resource URL has something special and authorizing-user-specific about it (with the invention of the "share URL" concept above)? Note that the share URL doesn't have to be a secret URL; it should be protected by UMA regardless (we'd need to think about how the host registers resources if we do make the "share URL" assumption). Is there some way we can handle current common API practice, where the endpoint URL is static and doesn't change per user?
- Host API dynamicism: Use case 2 could be called "host-initiated access"; this only works if the host uses a standard API that the requester can discover and work with. Do we need to build an alternative use case that assumes a proprietary API (akin to current OAuth usage), non-dynamic introduction of the parties, and requester-initiated access? How does scope work in that case – does the AM just end up recording the requester-offered scope?
- Redirection of requesting user: Do we need to bake a special claim request/response into UMA for handling the person-to-self flow (or at least usage of the web server user-authentication flow) in Step 2 so that the requester knows for sure to redirect the user to the AM? A requesting user who isn't Alice may not need to "authenticate" there, but they could (e.g.) provide a special code that was given to them by the authorizing user offline.