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