Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

Feedback from review with Tom SmedinghoffIssues:

  • Consider using initial capitals for all references to defined terms. (Currently they are highlighted with italics.)Consider broadening authorizing user to authorizing party if we want not to preclude these use cases in future.
  • Consider making all the term references internal links to elsewhere in the document where they're defined. (Anchors have been inserted if we want to do this.)
  • Consider whether or not we need to distinguish (and formally define) different kinds of intermediaries, such as authorization intermediaries, host intermediaries, and requester intermediaries. (Currently the distinctions have been removed on the theory that intermediaries are only talked about in order to dismiss them as irrelevant to access authorization agreements.)
  • Note that the word "endpoint" is unnatural for nontechnical readers, particularly in the formulation "endpoint in a protocol". Does this work sufficiently for techies that we don't have to be concerned about others? Does it make sense to talk about actors, roles, players, ...?
  • Consider revising "host service user" because it's too generic. How can we convey a better sense? If the "authorizing user" is the access controller, would the "host service user" the primary access-er? Yuck!
  • Do "policies and terms" need to be defined?
  • A graphic or two would really help here, e.g. to show that the "contract view" treats different parties as important compared to the "protocol view".(depends on custodianship discussion).

An

Anchor
authorizingauthz-userauthorizing
authz-user
authorizing user is a web user (a natural person) who provides configures an AM with access authorization policies and terms to an AM in order to instruct it how to make access decisions when a requester attempts to access a protected resource on a host. An authorizing user is the sole party capable of entering into an dictating access authorization agreement with terms to a requesting party.

A

Anchor
protected-resource
protected-resource
protected resource is an access-restricted resource (per as defined in [HTTP]) that can be obtained from a host with the authorization of an authorizing user, as carried out by an AM.An Anchoraccess-authz-agreementaccess-authz-agreementaccess authorization agreement is a contract entered into by an authorizing user and a requesting party, governing the requesting party's access to a protected resource.

An

Anchor
AM
AM
authorization manager (or AM) is an endpoint in the UMA software protocol that carries out an authorizing user's policies and terms for resource access by interacting, in the role of an HTTP server (per 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, and an .

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 direct parties to any access authorization agreementinvolved in demanding access authorization terms or making representations.

An

Anchor
access-authz-term
access-authz-term
access authorization term (or term) is a requirement for a representation that an authorizing user places on a requesting party, receipt of which is generally a condition for authorizing the requesting party's access to a protected resource.

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.

A

Anchor
representation
representation
representation is a statement of an affirmative or promissory nature that a requesting party makes in response to an authorizing user's access authorization term.

A

Anchor
claim
claim
claim is the technical expression in the UMA protocol of a representation, conveyed by by requester to an AM.

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 unilaterally in calculating authorization for access to a protected resource, without receiving claims from a requester.

A

Anchor
host
host
host is an endpoint in the UMA software protocol that interacts with AMs AMs in the role of an HTTP client (per as defined in [HTTP]) in order to receive and act on access decisions, and with requesters requesters in the role of an HTTP server (also per 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, and a .

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 direct parties to any involved in demanding access authorization agreementterms or making representations.

A

Anchor
host-service-user
host-service-user
host service user is a web user (a natural person) who interacts with a host service in order to use and configure it for resource hosting. In general, a user of a host service is identical to the authorizing user of the same resources at that host, but in special cases they may be different people.

A

Anchor
requester
requester
requester is an endpoint in the UMA software protocol that interacts with hosts hosts and AMs AMs in the role of an HTTP client (per 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, and a .

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 direct parties to any involved in demanding access authorization agreementterms or making representations, or 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 interacts 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 entering into an access authorization agreement with making representations to an authorizing user.

References

Anchor
HTTP
HTTP
[HTTP]
Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, "Hypertext Transfer Protocol