Page Comparison

...

Terminology in the protocol spec

Terms are capitalized here for clarity of definition, but are lowercase in the main body of the specification for readability. Note that in this specification, the word "profile" is used not only to refer to [WRAP] profiles, but also for the result of choosing one out of several options in a referenced specification in order to increase interoperability.

Authorizing User: A web user who configures an Authorization Manager Following is a new proposal for OAuth 2.0-based terms, now incorporated into the core protocol spec. Key definitions from the draft OAuth 2.0 specification ([OAuth20]) are reproduced here for ease of tracing UMA definitions that are dependent on them, though these OAuth definitions do not appear in the formal spec.

authorizing user: An UMA-defined variant of an [OAuth20] resource owner ("An entity capable of granting access to a protected resource."); a web user who configures an authorization manager with policies that control how it makes access decisions when a Requester requester attempts to access a Protected Resource protected resource at a Hosthost.

Authorization Manager authorization manager (AM): An UMA-defined variant of a WRAP Authorization Server an [OAuth20] authorization server ("An HTTP server capable of issuing tokens after successfully authenticating the resource owner and obtaining authorization. The authorization server may be the same server as the resource server, or a separate entity.") that carries out an Authorizing Userauthorizing user's policies governing access to a Protected Resourceprotected resource.

Protected Resource: A resource (at a Host) whose access is restricted. (Note that this differs from WRAP's definition of the same term.)

Hostprotected resource: An access-restricted resource at a host.

host: An UMA-defined variant of, respectively, a WRAP Protected Resource and WRAP Client, of an [OAuth20] resource server ("An HTTP server capable of accepting authenticated resource requests using the OAuth protocol.") that enforces access to the Protected Resources protected resources it hosts, as decided by an Authorization Managerauthorization manager.

Token Validation token validation URL: The URL at an Authorization Manager authorization manager that a Host uses host can use to validate an access token.

Claimclaim: A statement (in the sense of [IDCclaim]). Claims are conveyed by a Requester requester on behalf of a Requesting Party requesting party to an Authorization Manager authorization manager in an attempt to satisfy an authorizing user's policy. (Protected Resources resources may also contain Claimsclaims, but this is outside the view of the UMA protocol.)

Requesterrequester: An UMA-defined variant of a WRAP Client of [OAuth20] client ("An HTTP client capable of making authenticated requests for protected resources using the OAuth protocol.") that seeks access to a Protected Resourceprotected resource.

Requesting Partyrequesting party: A web user, or a corporation (or other legal person), that uses a Requester requester to seek access to a Protected Resourceprotected resource.

Additional terminology

Terms in this section do not appear in the protocol spec, but we have found it to be useful to define them in addition, for non-normative/discussion purposes.

Primary Resource Userprimary resource user: A web user who who interacts with a Host host to store and manage Protected Resources protected resources there. The Primary Resource User 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.

...

UMAnize: To make a host UMA-protected. (Thanks to Domenico for that one.)

Discussion

(See the Law.com dictionary for some helpful definitions of legal terms.)

Parties and legal responsibilities

The following diagram attempts to summarize the options for parties, as discussed below.

Image Removed

For our purposes in UMA 1.0, an authorizing user is always a natural person (a human being). 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 or a legal person. Legal persons are symbolized in the diagram by "factories", evoking a company or other organization.

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. Thus, some legal person such as a company may operate the service that hosts or requests a resource, or offers authorization services.

Here are the choices for requesting party:

...

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.

In cases where a claim constitutes acceptance of an access-sharing contract offer made by the authorizing user (as presented by the AM as his or her agent in requiring the claim), the authorizing user and requesting party are the parties to the contract, and all other legal or natural persons running UMA-related services involved in managing such access are intermediaries that are not party to the contract (though they might end up being third-party beneficiaries in some cases).

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.

ReferencesReferences

...