Lexicon
Terminology in the protocol spec
Following is a working lexicon, very much subject to change. Some or all of this lexicon may be added to the core protocol specification or other documents.
Issues:
- Consider broadening authorizing user to authorizing party if we want not to preclude these use cases in future.
Image Removed
Image Removed
Image Removed
An Anchor |
---|
authz-user | authz-user | authorizing user is a web user (a natural person) who uses a user agent (as defined in [HTTP]) to configure an AM with access authorization policies and terms, in order to instruct it how to make 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. An authorizing user is the sole party capable of dictating access authorization terms to a requesting party in the context of an UMA-based interaction.A Anchor |
---|
protected-resource | protected-resource | protected 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 in an AM's resource access decision.An Anchor |
---|
AM | AM | authorization manager (or AM) is an endpoint in the UMA protocol 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 instructions policies governing access to a protected resource by interacting, in the role of an HTTP server (as defined in [HTTP]), with hosts in order to convey resource access decisions and with requesters in order to determine their suitability for access.An Anchor |
---|
AM-app | AM-app | AM application is software that implements an AM.An Anchor |
---|
AM-service | AM-service | AM service is an AM application that is deployed on a network. The legal or natural person(s) who run an AM service are intermediaries that are not involved in stating access authorization terms or making representations.A Anchor |
---|
representation | representation | representation is a statement of an affirmative or promissory nature that a requesting party makes during its process of seeking access to a protected resource. (See also claim.)An Anchor |
---|
access-authz-term | access-authz-term | access authorization term (or term) is a requirement for a requesting party to make a representation to an authorizing user as one condition for access to a protected resource. (See also claim request.)A Anchor |
---|
claim | claim | claim is the technical expression in the UMA protocol of a representation, conveyed by a requester to an AM.A Anchor |
---|
claim-request | claim-request | claim request is the technical expression in the UMA protocol of an access authorization term, conveyed by an AM to a requester.An Anchor |
---|
access-authz-policy | access-authz-policy | access authorization policy (or policy) is an instruction an authorizing user gives an AM that the AM is capable of applying without requiring a claim from the requester in granting authorization for protected resource access.A Anchor |
---|
host | host | host is an endpoint in the UMA protocol that interacts with AMs in the role of an HTTP client (as defined in [HTTP]) in order to receive and act on protected resource access decisions, and with requesters in the role of an HTTP server (also as defined in [HTTP]) in order to respond to access attempts.A Anchor |
---|
host-app | host-app | host application is software that implements a host.A Anchor |
---|
host-service | host-service | host service is a host application that is deployed on a network. The legal or natural person(s) who run a host service are intermediaries that are not involved in stating access authorization terms or making representations.A Anchor |
---|
primary-resource-user | primary-resource-user | primary resource user is a web user (a natural person) who uses a user agent (as defined in [HTTP]) to interact with a host service in order to use it for resource hosting.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.
requesting party: A web user, or a corporation (or other legal person), that uses a requester to seek access to a protected 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 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.A Anchor |
---|
requester | requester | requester is an endpoint in the UMA protocol that interacts with hosts and AMs in the role of an HTTP client (as defined in [HTTP]) to attempt, and receive authorization for, access to a protected resource.A Anchor |
---|
requester-app | requester-app | requester application is software that implements a requester.A Anchor |
---|
requester-service | requester-service | requester service is a requester application that is deployed on a network. The legal or natural person(s) who deploy a requester service may be intermediaries that are not involved in stating access authorization terms or making representations; alternatively, one or them may be a requesting party.A Anchor |
---|
requesting-party | requesting-party | requesting party is either a legal person (such as a company running a requester service), or a natural person (a web user) who uses a user agent (as defined in [HTTP]) to interact with a requester service, in order to seek protected resource access on his/her/its own behalf. In either case, a requesting party is the sole party capable of making representations to an authorizing user in the context of an UMA-based interaction.References
Anchor |
---|
HTTP | HTTP | [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
[OAuth20] http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth.txt[WRAP] http://tools.ietf.org/html/draft-hardt-oauth-01 [hostmeta] http://tools.ietf.org/html/draft-hammer-hostmeta [IDCclaim] http://wiki.idcommons.net/Claim