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 and surrounding this whole topic, then the word "register" has only two uses left: resource sets (RSR) and claims redirection URIs.On Tue, Nov 1, 2016 at 6:18 PM, Eve Maler <eve@xmlgrrl.com> wrote: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.