I've made some edits on this stream; let me know if you have feedback. - Going from *the RS "registering a requested permission" for a client* to *the RS requesting (a set of) (one or more) permissions (on behalf of a client)*: This had both rhetorical and syntax components, as it turned out, because the config property formerly called *permission_registration_endpoint* is now *permission_endpoint*. But I think it makes things a LOT clearer, because it aligns things that used to be a bit out of whack, in that "requested permissions" can be ultimately singular or plural, particularly now that we allow an array of resource identifiers all at once, and an issued RPT can contain "granted permissions" singular or plural. You can see the result in these two commits: - "permission registration" --> "permission request" (rhetorical) https://github.com/KantaraInitiative/wg-uma/commit/158e73b733546cfe76b26da54... - "permission registration endpoint"-->"permission endpoint" (syntax) https://github.com/KantaraInitiative/wg-uma/commit/de6bf759d8a16e201f4b26739... - *PAT* now expands to *protection API access token*. This is, I think, a pretty minor rhetorical change and only appears in a couple of places -- and so far, the spec is even coy about whether the "A" is for "API" or "access"! But it has a lot of explanatory power. Still pondering *persisted claims token (PCT)*, whether it should try to align with *AAT* (A*T?) for hysterical raisins, and what its relationship should be with our *claim token* mechanism/name. Still would be glad for input. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Nov 4, 2016 at 11:20 AM, Eve Maler wrote:

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

FWIW: I’m fine with keeping the “RPT” name, but I think we should be clear in the spec that the RPT *is* an access token in the OAuth sense of the definition. — Justin

On Nov 14, 2016, at 6:49 AM, Eve Maler wrote:

Also still contemplating whether we should just replace RPT with access token. Pro: Saying "access token" falls right into the OAuth rhetorical slipstream. Con: We'd have a little bit of hassle distinguishing them from the other tokens floating around in the spec (PATs and PCTs or whatever we end up calling the latter), and we do place some distinct requirements on introspection responses (precise requirements still tbd), so RPTs/access tokens are not entirely "vanilla" tokens, all of which is why we gave them a name in the first place. Given this, my recommendation, since it appears that "requesting party" is not going away, is that that we keep the RPT name.

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

On Mon, Nov 14, 2016 at 3:24 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote: I've made some edits on this stream; let me know if you have feedback. Going from the RS "registering a requested permission" for a client to the RS requesting (a set of) (one or more) permissions (on behalf of a client): This had both rhetorical and syntax components, as it turned out, because the config property formerly called permission_registration_endpoint is now permission_endpoint. But I think it makes things a LOT clearer, because it aligns things that used to be a bit out of whack, in that "requested permissions" can be ultimately singular or plural, particularly now that we allow an array of resource identifiers all at once, and an issued RPT can contain "granted permissions" singular or plural. You can see the result in these two commits: "permission registration" --> "permission request" (rhetorical) https://github.com/KantaraInitiative/wg-uma/commit/158e73b733546cfe76b26da54... "permission registration endpoint"-->"permission endpoint" (syntax) https://github.com/KantaraInitiative/wg-uma/commit/de6bf759d8a16e201f4b26739... PAT now expands to protection API access token. This is, I think, a pretty minor rhetorical change and only appears in a couple of places -- and so far, the spec is even coy about whether the "A" is for "API" or "access"! But it has a lot of explanatory power. Still pondering persisted claims token (PCT), whether it should try to align with AAT (A*T?) for hysterical raisins, and what its relationship should be with our claim token mechanism/name. Still would be glad for input.

Eve Maler Cell +1 425.345.6756 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 11:20 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote: 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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 1, 2016 at 6:18 PM, Eve Maler mailto:eve@xmlgrrl.com> wrote: https://github.com/KantaraInitiative/wg-uma/issues/256 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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

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

All makes sense, thanks. In Core 09, the definition of RPT now says it's an OAuth access token, and the rationale for giving it a special name (from UMA1), regarding distinguishing it from the other tokens floating around, has been kept. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Nov 29, 2016 at 3:12 PM, Salvatore D'Agostino wrote:

+1, clarity is what matters, as well as an understanding of the tokens involved, perhaps a token cheat sheet…

*From:* wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@ kantarainitiative.org] *On Behalf Of *Justin Richer *Sent:* Tuesday, November 29, 2016 5:57 PM *To:* Eve Maler *Cc:* wg-uma@kantarainitiative.org UMA *Subject:* Re: [WG-UMA] Issue #256: Consider the naming of entities and concepts: token/ticket/registration terms

FWIW: I’m fine with keeping the “RPT” name, but I think we should be clear in the spec that the RPT *is* an access token in the OAuth sense of the definition.

— Justin

On Nov 14, 2016, at 6:49 AM, Eve Maler wrote:

Also still contemplating whether we should just replace *RPT* with *access token*.

- Pro:

- Saying "access token" falls right into the OAuth rhetorical slipstream.

- Con:

- We'd have a little bit of hassle distinguishing them from the other tokens floating around in the spec (PATs and PCTs or whatever we end up calling the latter), and we do place *some* distinct requirements on introspection responses (*precise* requirements still tbd), so RPTs/access tokens are not entirely "vanilla" tokens, all of which is why we gave them a name in the first place.

Given this, my recommendation, since it appears that "requesting party" is not going away, is that that we keep the RPT name.

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

On Mon, Nov 14, 2016 at 3:24 AM, Eve Maler wrote:

I've made some edits on this stream; let me know if you have feedback.

- Going from *the RS "registering a requested permission" for a client* to *the RS requesting (a set of) (one or more) permissions (on behalf of a client)*: This had both rhetorical and syntax components, as it turned out, because the config property formerly called *permission_registration_endpoint* is now *permission_endpoint*. But I think it makes things a LOT clearer, because it aligns things that used to be a bit out of whack, in that "requested permissions" can be ultimately singular or plural, particularly now that we allow an array of resource identifiers all at once, and an issued RPT can contain "granted permissions" singular or plural. You can see the result in these two commits:

- "permission registration" --> "permission request" (rhetorical) https://github.com/KantaraInitiative/wg-uma/commit/158e73b733546cfe76b26da54... - "permission registration endpoint"-->"permission endpoint" (syntax) https://github.com/KantaraInitiative/wg-uma/commit/de6bf759d8a16e201f4b26739...

- *PAT* now expands to *protection API access token*. This is, I think, a pretty minor rhetorical change and only appears in a couple of places -- and so far, the spec is even coy about whether the "A" is for "API" or "access"! But it has a lot of explanatory power.

Still pondering *persisted claims token (PCT)*, whether it should try to align with *AAT* (A*T?) for hysterical raisins, and what its relationship should be with our *claim token* mechanism/name. Still would be glad for input.

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

On Fri, Nov 4, 2016 at 11:20 AM, Eve Maler wrote:

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

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