...
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 Smedinghoff:
- 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".
An
Anchor |
---|
| authorizing-user |
---|
| authorizing-user |
---|
|
authorizing user is a web user (a natural person) who
interacts with provides policies and terms to an
AM service in order to instruct
an AM 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
forging entering into an
access authorization agreement with a
requesting party.
A
Anchor |
---|
| protected-resource |
---|
| protected-resource |
---|
|
protected resource is an access-restricted resource (per [HTTP]) that can be obtained from a
host with the authorization of an
AM and, indirectly, an authorizing user authorizing user, as carried out by an AM.
An
Anchor |
---|
| access-authz-agreement |
---|
| access-authz-agreement |
---|
|
access authorization agreement is a contract
forged entered into by an
authorizing user and a
requesting party, governing the requesting party's access to
protected resources controlled by the authorizing usera protected resource.
An
authorization manager (AM) is an endpoint in the UMA software protocol that
interactscarries out an authorizing user's policies and terms for resource access by interacting, in the role of an HTTP server (per [HTTP]), with
hosts in order to convey resource access decisions and with
requesters in order to determine their suitability for access. An
AM application is software that implements an
AM, and an
AM service is an AM application that is deployed on a network. The legal or natural person(s) who run an AM service are
authorization intermediaries that are not direct parties to any
access authorization agreement.
A
host is an endpoint in the UMA software protocol that interacts with
AMs in the role of an HTTP client (per [HTTP]) in order to receive and act on access decisions, and with
requesters in the role of an HTTP server (also per [HTTP]) in order to respond to access attempts. A
host application is software that implements a host, and a
host service is a host application that is deployed on a network. The legal or natural person(s) who run a host service are
hosting intermediaries that are not direct parties to any
access authorization agreement.
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
user who authorizes access to authorizing user of the same resources at
the same that host, but in special cases they may be different people.
A
requester is an endpoint in the UMA software protocol that interacts with
hosts and
AMs in the role of an HTTP client (per [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
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
application in a running service may be
requester intermediaries that
that are not direct parties to any
access authorization agreement, 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 run by a requesting intermediary, 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
forging entering into an
access authorization agreement with an
authorizing user.