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.
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: 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 entering into an access authorization agreement with a requesting party.A Anchor
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.
protected resource: An Anchor
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 resources resource at that host, but in special cases or they they may be different people.
UMAnitarian: An UMA WG participant.
UMAnize: To make a host UMA-protected. (Thanks to Domenico for that one.)A
References
Anchor | |||
---|---|---|---|
|
|
http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth.txt
Anchor | ||||
---|---|---|---|---|
|
http://tools.ietf.org/html/draft-hardt-oauth-01
Anchor | ||||
---|---|---|---|---|
|
http://tools.ietf.org/html/draft-hammer-hostmeta
Anchor | ||||
---|---|---|---|---|
|
http://wiki.idcommons.net/Claim