Nature of protected resource

API endpoint. For example, see the FireEagle developer documentation. The resource being protected is a single endpoint URL, with different options and parameters possible for using it. The possible scopes in today's location services tend to include (a) whether the requesting app (client) can write the user's location, and (b) to what degree the client can read the user's location. For example, see the FireEagle scope permissions documentation; the location-reading options include: no read access, as precise as possible, postal code level, neighborhood level, town level, regional level, state level, and country level.

Sharing models

Current OAuth-protected usage of location services such as FireEagle and BrightKite assumes a person-to-self sharing model, where Alice has login accounts at the various host and requester apps, and wants to instruct them to share her location among themselves on her own behalf; an UMA-enabled version of this would allow her to control such sharing centrally at her AM.

Nature of policies and claims

For person-to-self sharing, a typical policy might require the requesting party to be able to authenticate as Alice directly at the AM (that is, dictating a particular Step 2 web-server flow that uses normal OAuth user authentication), or might require a claim that it is an authenticated Alice asking for forge the connection.

Cardinality

This scenario is 1:1. There is no need to aggregate multiple resources from multiple hosts, for example.

Colocation

The same app might both read and write location data (by using different methods with the same API endpoint), which allows a requester app to write data to a host while still technically remaining a request. With today's OAuth-enabled location services, the location services also seem to be relatively "peer"-ish, in that they each have application galleries that support any one of them serving as an initial host. So it could be said that the same app might be a host for some users and a requester for others, and/or might be set up as both a host and a requester for the same user's location; however, the latter may be very confusing given current OAuth realities.

Host-AM relationship

Today's OAuth-enabled apps require static introduction and configuration, but the light weight and low security of these Web 2.0 services suggest that dynamic introduction is a possibility as long as the location API is well-known/standardized.

Protected resource discovery

Today's OAuth-enabled apps advertise this location in the process of static introduction and configuration, but with a well-known/standardized location API, it seems possible that a location service host could advertise its endpoint through dynamic means such hostmeta/XRD.