I didn't mention anything about the name of the requesting party claims endpoint in the previous note in this thread, but here's a proposal now.It's a pretty long name, and it's over-broad because it's not the only endpoint that can accept claims about the requesting party. Looking at the other endpoint names for a pattern, we have:
- token endpoint (comes from OAuth)
- authorization endpoint (comes from OAuth)
- (client) registration endpoint (we chose this name, though it's OAuth/OIDC-related)
- introspection endpoint (comes from the introspection spec)
- resource set registration endpoint (comes from RSR -- might change if we go for "protected resource")
- permission registration endpoint (comes from Core -- might change if we go for "(RS) requests a permission (on behalf of the client)")
There's a very short and noun-y flavor. Given this, claims interaction endpoint would suit well, vs. something like interactive claims-gathering endpoint. Keep in mind that it sort of pairs with the "claims redirection URI", the callback URI that we recommend the client register with the AS.Thoughts? I'll plan to go with claims interaction endpoint if no further input.On Fri, Nov 4, 2016 at 10:36 AM, Eve Maler <eve@xmlgrrl.com> wrote:Some thoughts about this:One of the remaining questions I have about our new claims-heavy regime is: Does it still support our previous popular use case of enabling the resource owner to have a policy condition of "The requesting party must present identity of X, authenticated to Y strength or assurance level Z?" Is it as simple as requesting a particular "acr" claim or set of trust vector claims through either route? This is a case of feature parity with UMA1, so it would be good to be clear.If that's good, then I'd be pretty comfortable consolidating terms as follows.Trust elevation could now be supplanted by authorization process (on the UMA wire), claims collection (part of it), (non-interactive) claims pushing (part of claims collection), (interactive) claims gathering (part of claims collection), and authorization assessment (internal to the AS). (I have an action from yesterday's call to work on the definition of authorization process; will do that!)Authorization API has already gone away, replaced by authorization interface (AS-client-RqP) and UMA grant (the AS-client part). This is a last call for whether we're happy with the name of the grant, and also perhaps the name of the URI for it, which includes "...uma-ticket". (I wonder if it it will be confused for the permission ticket.)We discussed right at the tail end of yesterday's call how I'll resurrect the profiled token introspection response (for now, go back to rev 05 to see it), but keep the token profiling extensibility point out. This would mean that the authorization data language would go away in favor of just permissions, which we could make clear is meant conceptually except in cases of introspection. Last call for replacing this word with something else. (Talking to access control experts, sometimes I'll describe them as entitlements -- not that this word isn't fraught either!)How we define claim isn't really quite right, since we say it's about "identity attributes of a requesting party". This excludes promissory claims. I've always struggled with this. If you have a brilliant idea, let me know.On Tue, Nov 1, 2016 at 6:11 PM, Eve Maler <eve@xmlgrrl.com> wrote:Darn, revised complete list as I missed some:
- authorization process (new)
- authorization interface (new)
- authorization API (obsolete)
- UMA grant (new)
- trust elevation (still used but some not crazy about it)
- gathered claims, claims gathering (intended to be used just for interactive)
- requesting party claims endpoint (original, sometimes accidentally subbed with "interactive claims-gathering endpoint")
- pushed claims, claim pushing
- claims collection (sort of new, intended to be used for both interactive and pushed)
- authorization data (generic original term for profitable data associated with RPT, concept used throughout)
- permissions (specific original term for resource set IDs + scopes (authorization data) associated with RPT)
- scopes (similar to OAuth notion of scopes with an imprecise amount of conceptual delta)
On Tue, Nov 1, 2016 at 6:03 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 authorization/claims terms from the GitHub issue:
- authorization process (new)
- authorization interface (new)
- authorization API (obsolete)
- UMA grant (new)
- trust elevation (still used but some not crazy about it)
- gathered claims, claims gathering (intended to be used just for interactive)
- requesting party claims endpoint (original, sometimes accidentally subbed with "interactive claims-gathering endpoint")
- pushed claims, claim pushing
- claims collection (sort of new, intended to be used for both interactive and pushed)
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.