I'm inclined to suggest that we go for maximal optimization of
understandability and minimization of confusion by *new UMA audiences*
here, and take the incompatibility and education hits. (Given that we're
working on an "UMA2" and all.) Then again, big changes should be well
motivated.
We could actually call the *requesting party token (RPT)* an *access token*.
It is consistent with our simplicity/OAuth alignment goal and our
development of an OAuth extension grant.
If we had it all to do over again, would we rename the *protection API
token (PAT)*? We've named it functionally from the RS's perspective, as in
"it gives the RS access to the protection API". Or we could name it
functionally from the RO's perspective, as in "it binds the RS and AS
together on the RO's behalf". Not sure that adds enough value to make a
disruptive change.
Keep in mind that we recommend that -- where possible -- OAuth should be
used in conjunction with OIDC so that the RO's identity is also captured.
This may or may not change our thinking. Actually, this makes me think that
clarifying that a PAT is a "protection API *access* token" would be
valuable, so that dealing with an associated protection API *ID* token is
legitimized.
*AAT* was always a pretty ugly abbreviation and not pronounceable
("aaaaaaaht"), so, nice that it's gone. We do still have perfect freedom to
consider *persisted claim token* (*PCT*), which has turned out to be
something of a cousin. The verb "persist" vs. the verb "save", fwiw, gets
ten times fewer hits on Google (40M vs. 3B) -- that is, it's kind of a
weird word. :-) Now that we've sharpened up the definition of what it does
and how it works, we can observe that it *saves* the results of an
*authorization
process* to be used in future ones. And the point of this from the
perspective of the RqP is typically to reduce future *claims gathering* if
possible. Food for thought if people want to propose other names. (It's
potentially gravy if we come up with a name that starts with an *A*, to
hark back to UMA1 days of yore. Authorization of requesting party token
(ART)? Kind of kidding.)
I don't see any problem with the phrase *permission ticket* (and I already
brought up uma-ticket in a previous thread, so let's leave it out of this
one), but wanted to discuss the language around "registering a (client's)
requested permission" / "registering for a permission ticket" (colloquial).
The idea is that a client wants the resource, and needs permission, so the
RS takes action on the client's behalf because the client is too dumb to
know what to do. But it's not really stated right. It's more like the RS
*requests* permission on the client's behalf, receiving a ticket in
response. (Hmm, which actually reveals a way in which UMA is more like
XACML than I thought -- it's just that the next several steps "explode out"
what would have been the PDP's permit/deny response. :-) ) Have I just
solved the problem? If we could avoid the word register in Sec 3.2
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-06.html#register-perm...
and surrounding this whole topic, then the word "register" has only two
uses left: resource sets (RSR) and claims redirection URIs.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Nov 1, 2016 at 6:18 PM, Eve Maler
https://github.com/KantaraInitiative/wg-uma/issues/256
This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *token/ticket/registration* terms from the GitHub issue:
- requesting party token (RPT) (original) - protection API token (PAT) (original) - authorization API token (AAT) (obsolete) - persisted claim token (PCT) (new) - permission ticket, registering a requested permission (original), registering for a permission ticket (colloquial) - uma_ticket (new; in the URL of the UMA grant type) - register a resource set (original)
For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl