Page Comparison

...

• 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 (H1) and HipHappeningPlaces (HH2) 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

...

This scenario assumes that Alice has an account at each of AM, H1, HH2, 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 scenario assumes that AM, HH1, 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 H uses H1 and H2 use a hypothetical standard location API that R1 and R2 are configured to understand, and that H exposes an API 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).

...

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

1. H H1 asks Alice to choose an AM to protect her location information in HH1
2. Alice tells H H1 her preferred AM
3. H H1 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 HH1'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)
5. Alice is redirected back to H 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

1. Alice visits H H1 and logs in as Alice-on-HH1
2. Alice decides to share access to her location information in H H1 with R1 (if UC1 use case #1 has not been done, it is must be done at this time)
3. Alice asks H H1 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 H1 and asks it to set up access to her location information there
6. R1 attempts to access the URL and discovers H H1 uses a location API that R1 understands
7. H1 redirects R1 gets redirected to the AM as unauthorized
8. The AM tells R1 it needs to provide a claim acknowledging the offered scope (need to standardize this claim request/response)
9. R1 sends the claim to AM
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

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.

Alice Shares HotLocale Location Access with RoadWarrior

...

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.