Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Terminology in the protocol spec

(This text has now been added to the spec.)

An Anchorauthz-userauthz-userauthorizing user is a web user who uses a user agent (as defined in [HTTP]) to configure an AM with access authorization policies to instruct it how to make 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 attempts to access a protected resource on at a host.

A Anchorprotected-resourceprotected-resourceprotected resource is an access-restricted resource (as defined in [HTTP]) that can be obtained from a host with the authorization of an authorizing user, as transmitted by an AM.An AnchorAMAMauthorization manager (or AM) is an UMA protocol endpoint authorization manager (AM): An UMA-defined variant of 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 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 Anchorpolicypolicypolicy is an instruction an authorizing user gives an AM to govern its calculation of access authorization decisions. A policy may involve dictating a requirement for a requester to provide one or more claims.A Anchorclaimclaimclaim is a statement (as defined in [IDCclaim]) conveyed by a requester to an AM in an attempt to satisfy a policy.A Anchorhosthosthost is an UMA protocol endpoint that interacts with AMs in the role of an HTTP client and with requesters in the role of an HTTP server (as defined in [HTTP]), in order to allow an authorizing user to control access to protected resources at that host.A Anchorrequesterrequesterrequester is an UMA protocol endpoint that interacts with hosts and AMs in the role of an HTTP client (as defined in [HTTP]) to gain authorized protected resource.

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

host: An UMA-defined variant 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 it hosts, as decided by an authorization manager.

token validation URL: The URL at an authorization manager that a host can use 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 an authorizing user's policy. (Protected resources may also contain claims, but this is outside the view of the UMA protocol.)

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

Anchorrequesting -partyrequesting-partyrequesting party is a party: A web user, or a corporation (or other legal person), that uses a requester to seek access to a protected resource access on his or her or its own behalf.

Additional terminology

A Anchorprimary-resource-userprimary-resource-userprimary resource user is a web user who uses a user agent (as defined in [HTTP]) to interact with a host in order to use it for resource hostingTerms 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 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 of the same resource at that host, or they they may be different people.

Discussion

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

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 run by Orbitz"). It's possible, though unlikely in the typical case, that Bob will deploy an online service on his own behalf that manages requesting access to a resource of Alice's; 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.

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.

References

AnchorHTTPHTTP[HTTP]
Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, "Hypertext Transfer ProtocolUMAnitarian: An UMA WG participant.

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

References

Anchor
OAuth20
OAuth20
[OAuth20]
http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth.txt

Anchor
WRAP
WRAP
[WRAP]
http://tools.ietf.org/html/draft-hardt-oauth-01

Anchor
hostmeta
hostmeta
[hostmeta]
http://tools.ietf.org/html/draft-hammer-hostmeta

Anchor
IDCclaim
IDCclaim
[IDCclaim]
http://wiki.idcommons.net/Claim