Eve, Just an editorial note: In UMA Grant, there is a glossary in section 1.3 (Abstract Flow). It says "Following are key concepts relevant to this specification," but it doesn't jump out at you. I was looking for a glossary in the TOC, and couldn't find it. And then in UMA Federated Authz, there is no glossary. You could perhaps reference the Glossary from Federated Authz to UMA Grant, but some of the definitions maybe needs to be tweaked. For example, I was looking at the definition of permission ticket: "A correlation handle, initially passed to the client by the resource server" That makes sense for UMA grant, but for federated Authz, it probably makes sense to mention the AS. - Mike
I went away from a formal Terminology section in V2 because 6749 doesn't have one (trying to track the language and structure of OAuth much more closely). FWIW, I did get some feedback from one OAuth person I specially reached out to that the "concepts section" was very effective. The definition of permission ticket in Grant is accurate even when the full context of FedAuthz is taken into account. Are you looking at rev 05? It seems to meet your goal. "A correlation handle, initially passed to the client by the resource server and subsequently exchanged during the authorization process between the client and authorization server." [emphasis added] And rev 05 of FedAuthz does say this: "This specification uses all of the terms and concepts in [UMAGrant]. This figure introduces the following new concepts: ..." Eve Maler (sent from my iPad) | cell +1 425 345 6756
On May 27, 2017, at 3:46 PM, Mike Schwartz <mike@gluu.org> wrote:
Eve,
Just an editorial note:
In UMA Grant, there is a glossary in section 1.3 (Abstract Flow). It says "Following are key concepts relevant to this specification," but it doesn't jump out at you. I was looking for a glossary in the TOC, and couldn't find it.
And then in UMA Federated Authz, there is no glossary.
You could perhaps reference the Glossary from Federated Authz to UMA Grant, but some of the definitions maybe needs to be tweaked. For example, I was looking at the definition of permission ticket: "A correlation handle, initially passed to the client by the resource server" That makes sense for UMA grant, but for federated Authz, it probably makes sense to mention the AS.
- Mike _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
permission ticket - "A correlation handle, initially passed to the client by the resource server and subsequently exchanged during the authorization process between the client AND AUTHORIZATION SERVER." [emphasis added]
What about something like: "A correlation handle, created by the AS in response to a resource registration request or interactive claims gathering process, that is subsequently exchanged for an RPT token." I think this is more generic because you could get back a rotated permission ticket during interactive claims gathering. Also, the fact that the AS both generates the ticket, and issues the RPT gives more meaning to the "correlation". The RS is just passing it along. - Mike
Hmm, maybe. It's not in response to resource registration but rather resource request (client) --> permission request (RS, formal in the case of FedAuthz or informal if FedAuthz isn't being used). That's why the wording was fuzzed. Also, "exchange" isn't right because it's not a one-for-one swap as if it were an authorization code. (I also notice that we left out saying "correlation handle *for requested permissions*".) How about this instead? It's a bit detailed, but does explain in words what people are seeing in the swimlane, does mention all three entities, and rectifies the problem with not mentioning what the handle correlates. :-) (I would then also move this definition after the definition for "permission".) "A correlation handle representing requested permissions that is created and maintained by the authorization server, initially passed to the client by the resource server, and presented by the client at the token endpoint and during requesting party redirects." *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, May 28, 2017 at 3:18 PM, Mike Schwartz <mike@gluu.org> wrote:
permission ticket -
"A correlation handle, initially passed to the client by the resource server and subsequently exchanged during the authorization process between the client AND AUTHORIZATION SERVER." [emphasis added]
What about something like:
"A correlation handle, created by the AS in response to a resource registration request or interactive claims gathering process, that is subsequently exchanged for an RPT token."
I think this is more generic because you could get back a rotated permission ticket during interactive claims gathering. Also, the fact that the AS both generates the ticket, and issues the RPT gives more meaning to the "correlation". The RS is just passing it along.
- Mike
That's *much* better. - Mike On 2017-05-28 18:46, Eve Maler wrote:
Hmm, maybe. It's not in response to resource registration but rather resource request (client) --> permission request (RS, formal in the case of FedAuthz or informal if FedAuthz isn't being used). That's why the wording was fuzzed. Also, "exchange" isn't right because it's not a one-for-one swap as if it were an authorization code. (I also notice that we left out saying "correlation handle _for requested permissions_".)
How about this instead? It's a bit detailed, but does explain in words what people are seeing in the swimlane, does mention all three entities, and rectifies the problem with not mentioning what the handle correlates. :-) (I would then also move this definition after the definition for "permission".)
"A correlation handle representing requested permissions that is created and maintained by the authorization server, initially passed to the client by the resource server, and presented by the client at the token endpoint and during requesting party redirects."
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, May 28, 2017 at 3:18 PM, Mike Schwartz <mike@gluu.org> wrote:
permission ticket - "A correlation handle, initially passed to the client by the resource server and subsequently exchanged during the authorization process between the client AND AUTHORIZATION SERVER." [emphasis added]
What about something like:
"A correlation handle, created by the AS in response to a resource registration request or interactive claims gathering process, that is subsequently exchanged for an RPT token."
I think this is more generic because you could get back a rotated permission ticket during interactive claims gathering. Also, the fact that the AS both generates the ticket, and issues the RPT gives more meaning to the "correlation". The RS is just passing it along.
- Mike
participants (2)
-
Eve Maler -
Mike Schwartz