...
(See the Law.com dictionary for some helpful definitions of legal terms.)
Parties and legal responsibilities
For our purposes in UMA 1.0, an authorizing user is always a natural person (a human being). By contrast, a . We foresee use cases where the authorizing party could be a non-human, but our 1.0 scope sticks to human beings in this role to ensure that we think about how to craft the user experience for this person (who is the all-important "user" in UMA!). An authorizing user may set policies at the AM that end up legally binding him/her, depending on the claims coming from the requesting party in response.
A requesting party may be either a natural person (which we may think of as person-to-person sharing, such as "Alice to Bob" with the help of various online services in the middle), or it may be a legal person such as a company (which we may think of as person-to-service sharing because the service is run by a corporation or other organization, such as "Alice to a survey application run by InfoUSA").
It's possible, though unlikely in the typical case, that Bob will deploy an online service on his own behalf that manages the requesting of access to a resource of Alice's ("Alice to Bob's homegrown app"); in that case, it would be person-to-person just as in the first case. The nature of required claims could be different depending on which kind of sharing is taking place.
ISSUE: is this correct? Is this an equal option everywhere person-to-service is an option? In some cases, Alice herself will deploy an online service on her own behalf, for which it's convenient to set up a service-access relationship with some other service that Alice uses as a host. In this way, Alice can achieve person-to-self sharing ("Alice's calendar host to Alice's homegrown calendar subscription app"), which is akin to the type of data sharing and service access enabled by OAuth and WRAP with the addition of the centralized authorization manager component.
So a requester can act on behalf of several different types of requesting party, which differ in the type of profile that the requester (or rather its embedded WRAP client component) must use to request an access token from the AM (or rather from the AM's embedded WRAP authorization server component):
...
Type of sharing
...
Example
...
WRAP profile type
...
Person-to-person
...
Alice allows Bob, using a popular Web 2.0 address book compilation service, to retrieve her home address from her personal datastore service (host)
...
Autonomous client (possibly with an invisible-to-UMA interaction with Bob to gather his consent or ask him to provide more information to be packaged up as claims)
...
Person-to-service
...
Alice allows InfoUSA's online service to collect her demographic data from a host site where she stores it
...
Autonomous client (where InfoUSA is the requesting party)
...
Person-to-self
...
Alice allows her own requester app to access her geolocation hosting service in order to set and get her current location
...
or a legal person.
The AM and requester protocol endpoints, the software that implements them, and the services that deploy them are just tools to help the parties get to a desired result. However, the requesting party "behind" these tools is a party that may be held legally responsible for any claims made to the authorizing user. Here are the choices for requesting party:
- Requesting party is a natural person, that is, a human being
- That person is the same as the authorizing user (person-to-self sharing)
- That person operates the service that runs the requester endpoint ("Alice authorizes herself to see her geolocation at a host, using her own homegrown requester app that logs travel")
- That person uses some third-party service that runs the requester endpoint as an intermediary, with which he/she has a separate agreement for terms of use ("Alice authorizes herself to subscribe to her calendar at host Googol Cal, using the popular Schedewl online app"): A
- That person operates the service that runs the requester endpoint ("Alice authorizes herself to see her geolocation at a host, using her own homegrown requester app that logs travel")
- That person is different from the authorizing user (person-to-person sharing)
- That person operates the service that runs the requester endpoint ("Alice authorizes Bob to see her geolocation at a host, using his own homegrown requester app that tracks her travel")
- That person uses some third-party service that runs the requester endpoint as an intermediary, with which he/she has a separate agreement for terms of use ("Alice authorizes Bob to subscribe to her calendar at a host, using the popular Schedewl online app where he has an account"): X
- That person operates the service that runs the requester endpoint ("Alice authorizes Bob to see her geolocation at a host, using his own homegrown requester app that tracks her travel")
- That person is the same as the authorizing user (person-to-self sharing)
- Requesting party is a legal person, such as a company (person-to-service sharing)
- That legal person operates the service that runs the requester endpoint on its own behalf ("Alice authorizes the survey company DataSuck to pull copies of her self-asserted demographic data on an ongoing basis")
- That legal person operates the service that runs the requester endpoint on the behalf of some person, with whom it has a separate agreement for terms of use
- That person is the same as the authorizing user ("Alice authorizes Schedewl to subscribe to her calendar at host Googol Cal, acting on behalf of her own account at Schedewl"): B
- That person is different from the authorizing user ("Alice authorizes Schedewl to subscribe to her calendar at host Googol Cal, acting on behalf of Bob's account at Schedewl"): Y
- That person is the same as the authorizing user ("Alice authorizes Schedewl to subscribe to her calendar at host Googol Cal, acting on behalf of her own account at Schedewl"): B
- That legal person operates the service that runs the requester endpoint on its own behalf ("Alice authorizes the survey company DataSuck to pull copies of her self-asserted demographic data on an ongoing basis")
Note that 1.a.ii and 2.b.i are protocol alternatives (denoted with A and B) for what could be the same basic kind of authorized access. In the first, the authorizing user and the requesting party are both Alice, and if any claims are required she supplies them to herself, but she has chosen to use some service run by a third party to manage requests for access. In the second, Alice uses the same such service but expects it to speak for itself in responding to demands for claims (possibly providing claims about her in the process).
Similarly, 1.b.ii and 2.b.ii are protocol alternatives (denoted with X and Y). In the first, Alice authorizes Bob for access, and Bob happens to use an intermediary service to help manage his requests. In the second, Bob uses the same such service but expects it to speak for itself in responding to demands for claims (again, possibly providing claims about him in the process).
We are actively researching this issue. See the notes from UMA telecon 2010-03-18 for discussion about the impact of choosing one alternative over another.
Mapping requesting parties to profiles for getting access tokens
We suspect that certain sharing patterns lend themselves to choosing different profiles for UMA's step 2 (getting a token).
- Person-to-self sharing could possibly use any profile of the WRAP user delegation type, since the same person would have an account on the requester and AM sides.
- Person-to-service sharing could possibly use any profile of the WRAP autonomous client type, since the service itself operates the WRAP client that is embedded in the UMA requester.
- Person-to-person sharing could also possibly use any profile of the WRAP autonomous client type, since everyone and everything on the requesting side is "autonomous" with respect to the authorizing side. However, an entirely new set of profiles might be appropriate instead, to take into account the requesting person's personal involvement in providing claims, confirming agreements, etc.
We are actively researching this issue.
The nature of claims
A claim may be affirmative, representing a statement of fact (as asserted by the requesting or another claim issuer); or promissory, a promise (as asserted by the requesting party specifically to the authorizing user). A statement of fact might be "The requesting party is over 18 years of age." A promise might be "The requesting party will adhere to the specific Creative Commons licensing terms indicated by the AM." There are technical dimensions to expressing and conveying claims, but since UMA strives to provide enforceability of resource-access agreements, there may also be legal dimensions.
...