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 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#uma-bearer-to... 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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Nov 1, 2016 at 6:11 PM, Eve Maler 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)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:03 PM, Eve Maler wrote:

...

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 *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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

Completing this thread for now, Core rev 07 contained the edits proposed above and discussed/agreed in telecon 2016-11-10. No other changes planned at this point. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, Nov 6, 2016 at 6:01 PM, Eve Maler wrote:

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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 10:36 AM, Eve Maler 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 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#uma-bearer-to... 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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:11 PM, Eve Maler 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)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:03 PM, Eve Maler wrote:

...

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 *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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

Great, thank you for the feedback. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sat, Nov 12, 2016 at 9:44 PM, Justin Richer wrote:

+1 to “claims interaction endpoint”

— Justin

On Nov 12, 2016, at 5:48 AM, Eve Maler wrote:

Completing this thread for now, Core rev 07 contained the edits proposed above and discussed/agreed in telecon 2016-11-10. No other changes planned at this point.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Nov 6, 2016 at 6:01 PM, Eve Maler wrote:

...

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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 10:36 AM, Eve Maler 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 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#uma-bearer-to... 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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:11 PM, Eve Maler 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)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:03 PM, Eve Maler wrote:

...

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 *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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma