Lexicon
Lexicon draft destined for 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 RemovedNon-normative examples provided here (TBS!) might or might not be included in the spec. The diagrams were removed temporarily because they are out of date.
An
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 access decisions when a
requester attempts to access a
protected resource on 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 interactionA
Anchor |
---|
| primary-resource-user |
---|
| primary-resource-user |
---|
|
primary 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 hosting. 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 |
---|
| 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 by an
AM's resource access decision.
An
authorization manager (or
AM) is an
endpoint in the UMA protocol
endpoint 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 A
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.)policy 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
claim is
the technical expression in the UMA protocol of a representation, a statement (as defined in [IDCclaim]) 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 an attempt to satisfy a requirement for access.
A
host is an
endpoint in the UMA protocol
endpoint 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. The primary resource user may be identical to the authorizing user of the same resource at that host, or they they may be different peopleallow an authorizing user to control access to protected resources at that host.
A
requester is an
endpoint in the UMA protocol
endpoint that interacts with
hosts and
AMs in the role of an HTTP client (as defined in [
HTTP]) to
attempt, and receive authorization for, gain authorized access to a
protected resource.
A
Anchor |
---|
| requesterrequesting-apppartyrequester |
---|
| requesting-appparty |
---|
|
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.requesting party is a web user, or a corporation (or other legal person), that uses a requester to seek protected resource access on his or her or its own behalf.Discussion of a legal bent
(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 in typical cases 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. Do we need to define the term "primary resource user" in the spec itself, if this is the case?
References
[HTTP] Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, "Hypertext Transfer Protocol