...
Terminology in the protocol spec
(This text has now been added to the spec.)
An Anchor
Authorizing User: A web user who configures an Authorization Manager with policies that control how it makes access decisions when a Requester attempts to access a Protected Resource at a Host.
Authorization Manager (AM): An UMA-defined variant of a WRAP Authorization Server that carries out an Authorizing User's policies governing access to a protected resource by interacting in the role of an HTTP server (as defined in [HTTP]) with hosts and requesters.A Anchor
Protected Resource: A resource (at a Host) whose access is restricted. (Note that this differs from WRAP's definition of the same term.)
Host: An UMA-defined variant of, respectively, a WRAP Protected Resource and WRAP Client, that enforces access to the Protected Resources it hosts, as decided by an Authorization Manager.
Token Validation URL: The URL at an Authorization Manager that a Host uses to validate an access token.
Claim: A statement (in the sense of IDCclaim). Claims are conveyed by a Requester on behalf of a Requesting Party to an Authorization Manager in an attempt to satisfy user policy. (Protected Resources may also contain Claims, but this is outside the view of the UMA protocol.)
Requester: An UMA-defined variant of a WRAP Client that seeks access to a Protected Resource.
Requesting Party: A web user, or a corporation (or other legal person), that uses a requester Requester to seek protected resource access on his or her or its own behalfaccess to a Protected Resource.
Additional terminology
A Anchor
Primary Resource User: A web user who who interacts with a Host to store and manage Protected Resources there. The Primary Resource User may be identical to the authorizing user Authorizing User of the same resource at that host, or they they may be different people.
...
For our purposes in UMA 1.0, an authorizing user is always a natural person (a human being). By contrast, a requesting party may be 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 travel website survey application run by OrbitzInfoUSA").
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 | User delegation (in which Alice, while interacting with her own requester app, is redirected to "herself" at the AM to log in and authorize the host-requester connection) |
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.
...
Where the primary resource user and the authoring user differ, there is likely to be an interaction (invisible to UMA) at the host service that allows (or forces) the primary resource user to designate an authorizing user, and an agreement that the authorizing user acts as the primary resource user's agent or guardian or similar.
References
Anchor | ||||
---|---|---|---|---|
|
http://www.ietf.org/rfc/rfc2119.txt
Anchor | HTTP | HTTP |
---|
Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, "Hypertext Transfer Protocol
|
http://tools.ietf.org/html/draft-hardt-oauth-01
Anchor | ||||
---|---|---|---|---|
|
http://tools.ietf.org/html/draft-hammer-hostmeta
Anchor | ||||
---|---|---|---|---|
|
http://wiki.idcommons.net/Claim