Consider the naming of entities and concepts

[xmlgrrl]

Experience (legal subgroup, OAuth work, IoT, etc.) is giving us greater perspective on what would make the best names for various UMA entities and concepts. We have an opportunity coming up to do some refactoring. Here are some candidates for consideration:

• resource owner / grantor / ...
• requesting party / grantee / ... (and confusion vs. a "relying party")
• resource set / protected resource / resource / ...
• confusion around an UMA client vs. an OAuth client...
• confusion around registering permissions vs. registering a (permission) ticket vs. registering resource set(s) for getting a ticket...
• trust elevation vs. claims gathering (interactive exclusively?) vs. claims pushing vs. a so-far nonexistent description for generic claims collection by the AS...
• persisted claims token / saved claims token / ... (new)
• UMA grant / ... (new)

There may be others.

[xmlgrrl]

requesting party token / ...

[xmlgrrl]

requesting party claims endpoint / claims gathering endpoint / claims-gathering endpoint / interactive claims gathering endpoint / interaction endpoint / ...

[xmlgrrl]

Regarding the "trust elevation" item: Above I mention "generic claims collection", and just wanted to note that "claims collection" might make a fine overall description for both pushed and interactively gathered claims.

[xmlgrrl]

policies / something more generic like "configuration of authorization options at the authorization server" / ...

Policies are out of band, and so UMA provides absolutely no guidance about what these are supposed to be. I've had some conversations with Allan F about this. However, going through the spec just now, the word is used a fair amount, and given that we're defining what is primarily an asynchronous grant flow, I think it would be a drag not to have a shorthand like "policy/policies" handy to refer to this concept. Worth discussing?

[xmlgrrl]

authorization data (the generic, extensibility-ready name for stuff that is associated with an RPT in UMA1) / permissions (the default stuff that is associated with an RPT in UMA1) / scopes (the stuff that is associated with or goes into an OAuth access token / ...

[xmlgrrl]

configuration data / discovery document / ...

[xmlgrrl]

Make sure to revisit the spiral, the new diagrams, and the ASCII diagrams when we settle the terminology.

[xmlgrrl]

Regarding configuration data/discovery document / ..., note that we currently have the actual "config data" residing at an "/uma2-configuration" directory at the server's well-known location (was "/uma-configuration" before). Should we consider changing the name of the directory if we change the name of the concept?

[nynymike]

I don't think a folder is even needed. Just "uma-configuration" is specific enough...

[xmlgrrl]

Hmm. I just checked, and in UMA V1.0.x, it was "... at its host-meta [RFC6415] location". So this is a side-issue we can discuss to see if it was overly prescriptive.

[xmlgrrl]

authorization process / trust elevation / claims collection / ...

We've now formally defined "authorization process" in the spec, as of rev 06.

[xmlgrrl]

We've discussed pretty much "all of the above" at this point, with two remaining exceptions:

• Whether persisted claim token (PCT) is here to stay vs. some other name. We changed it from "saved consent token (SCT)" early on, but never had the discussion after that.
• There's been some confusion over access token vs. claim token. There used to be a definition of "token" that squared the circle, but I removed it in early 2.0 editing ("A packaged collection of data meant to be transmitted to another entity. A token could be used for authorized access (an "access token"), or could be used to exchange information about a subject (a "claim token")."). Should we simply add it back in an appropriate place, or consider using something like "claim assertion" instead, or what?

[jricher]

What you describe in the "token" definition is not a token. An access token is not a packaged collection of data necessarily: it could be (and often is) a reference. What you're describing is an assertion, and if we need something like that for claims we could call it an assertion, but I'm not seeing a need for such a bundle term. The client can submit claims using an assertion, but where else would we need it?

[xmlgrrl]

I agree we overstated the case regarding transmission in the flesh vs. by reference. I don't really have the heart to split hairs around ID tokens, claims, assertions, artifacts, and the rest of it. (I could tell you stories about why the SSTC chose "assertion" vs. other options lying around... :-) ) For our purposes, what's clear and unambiguous definitionally?

[xmlgrrl]

We also have a third question, I'm realizing as I edit Sec 3.6 in the rev ~10 era. Is it really right to have an "authorization interface" encompassing the "UMA grant"? Our logic was, I think, that it's possible (and often desirable, in a post-AAT world) for claims gathering to happen even before a request for an RPT. Do we have to be more detailed about this? It just feels weird that the client mediates the interactive flow too but it's not the UMA grant yet (even though I realize they aren't using the token endpoint). I have to edit Sec 3.6 in a few subtle ways assuming our logic still holds.

[jricher]

In my view, the whole process is the UMA grant. Which is to say, the RqP's story of getting a token is a new grant type. That includes the interaction endpoint and calls to the token endpoint, just like in OAuth's authorization code grant type it includes both the authorization endpoint and the calls to the token endpoint.

[xmlgrrl]

In ad hoc discussion post-UMA telecon 2017-01-12, we discussed this last issue (authorization interface vs. UMA grant) and came to some consistent conclusions that were sufficient for driving new and clarifying spec edits.

[xmlgrrl]

As of today, we've timed out on considering a name change to PCTs per the call made on Jan 12, and the authorization interface vs. UMA grant issue was taken care of (conceptually at least). What remains is the question of "token" language for identification, sets of claims, access, and whatever purpose.

In order not to spend too much time on this, what I propose is simply to define the term "claim token" (encompassing "ID token" and other sorts of conveyances of information about a subject by value and reference within the definition), since we define "persisted claims token (PCT)" and also "requesting party token (RPT)". This should take care of any confusion.