[WG-UMA] Requester and authorizer definitions
Eve Maler
(As already mentioned, I suspect we're going to need an auxiliary document that explains the legal/contractual/liability context in which UMA operates, and possibly even explores the ramifications of person-to-person vs. person-to-service sharing.)
Let's see how this flies...
====
authorization manager (AM): An HTTP server (per [HTTP]) capable of interacting with hosts in order to convey resource access decisions, and with requesters in order to determine their suitability for access.
authorization manager (AM) application: Software that embodies an AM.
authorizing intermediary: A party other than the authorizing party or requesting party, engaged by the former to assist in fielding and granting access requests to a protected resource made by the latter.
authorizing party: A party capable of offering agreement terms to a requesting party, for the purpose of granting access to a protected resource.
authorizing user: A web user capable of indirectly controlling access by requesters to protected resources on hosts, by instructing an AM how to make access decisions; a user of an AM application.
host: An online service capable of interacting with AMs in the role of an HTTP client (per [HTTP]) in order to receive and act on access decisions, and interacting with requesters in the role of an HTTP server (per [HTTP]) in order to respond to access requests.
host application: Software that embodies a host.
protected resource: An access-restricted resource (per [HTTP]) that can be obtained from a host with the authorization of an AM and, indirectly, the authorizing user.
requester: An HTTP client (per [HTTP]) capable of interacting with hosts and AMs to request, and receive access to, protected resources.
requesting application: Software that embodies a requester.
requesting intermediary: A party other than the authorizing party or requesting party, engaged by the latter to assist in requesting, receiving, and fulfilling access to a protected resource controlled by the former.
requesting party: A party capable of meeting and accepting agreement terms offered by an authorizing party, for the purpose of receiving access to a protected resource.
requesting user: A web user capable of indirectly seeking access to protected resources on hosts through a requester; a user of a requesting application.
====
Some observations, now that I've gotten this far:
I'm not sure it really is useful to go as far as listing the "legal" (party/intermediary) definitions in the actual protocol spec. The "application" (software) level will probably be helpful e.g. in non-normative example text in the spec, and note that I conflated the protocol and application level a bit with the "a user of X" formulation, but the "party" stuff is almost in a fourth dimension or something; it cuts across all the other stuff without touching it.
I choked when it came to two important categories of terms and could use advice big-time on this:
- The "hosting party" (or is that "hosting intermediary" on behalf of the hosting user??): I think we're going to need it for a full explanation of liability implications, but it felt way too heavy to try and add it here.
- The "hosting user" (user of a host application, who is also the hosting party??): Not only do we need this for the above, but we need it to discuss the custodian scenario in which the authorizing user (party?) and the hosting user may be different people. (Even if we end up deferring the custodian scenario, it would be nice to nail this down anyway.) Related to this, is it helpful for us to define and use the phrase "resource owner" for any purpose? The OAuth spec defines this as "An entity capable of accessing and controlling protected resources by using credentials to authenticate with the server." We'd have our own take, of course, perhaps more aligned with "authorizing user" -- but might this help us or hurt us when it comes to the custodian problem?
Finally, in reviewing Joe's original proposal, I realize now that he proposed "requesting client" to balance his recommendation for "requesting service". I did consider the "client" language, and also explicitly adding the word "endpoint" to the protocol endpoints, but we worked hard to come up with easily identifiable terms (AM, host, requester) for the endpoints and I didn't see a reason to normalize. A foolish consistency is the hobgoblin of little minds...
Thoughts? (I'm lookin' at you, Joe and Tom S.!)
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler
Eve