New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authorization server is not explicitly required to match the permission ticket's extent to the requested permission's extent #175
Comments
Eve, if what the AS is a subset (and that's true) then your proposed wording is not correct - i.e. the permission ticket returned to the RS may not be what the RS registered. Maybe this sentence is not the best place to put this information. We already have an entire paragraph: Note: The resource server is free to choose the extent of the requested permission that it registers, as long as it minimally suffices for the access attempted by the client. For example, it can choose to register a permission that covers several scopes or a resource set that is greater in extent than the specific resource that the client attempted to access. Likewise, the authorization server is ultimately free to choose to partially fulfill the elements of a permission request based on incomplete satisfaction of policy criteria, or not to fulfill the request. |
Clearly we have differing interpretations about what was possible to do, so we need to figure out what we really mean, for interoperability. FWIW, I had always assumed that the AS was just "saving state" on behalf of the RS so that the approach made later by the client would result in the AS testing the client/RqP's suitability for whatever extent of access the RS had registered. The last sentence was intended to mean that if the client/RqP turns out to be only partially suitable at that later time, say, by being able to supply only some of the needed claims, the AS is free to partially fulfill the set of permissions or not fulfill it at all. (I now realize that "permission request" is a really ambiguous phrase. It appears nowhere else.) If instead we mean "subset" (⊆, I assume, not ⊂) we should indeed spell that out. |
OK, I understand your point. Then the following sentence should be refactored: "Likewise, the authorization server is ultimately free to choose to partially fulfill the elements of a permission request based on incomplete satisfaction of policy criteria, or not to fulfill the request." (X) In this case what you proposed: "The authorization server returns a permission ticket for the resource server to give to the client in its response that represents what the resource server registered." is fine (as long as X is clarified/removed. |
This is a small tweak to reapply one fix that didn’t get made in the last “fixed commit”.
Proposed, discussed, and reviewed in UMA telecon 2015-08-27. We can close this. |
In #165, Justin noted that "The ticket has (what is assumed but not stated to be) a subset of the scopes that the RS is registered with" (Core Sec 3.2: https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.2). Indeed, that's true.
The right place to put such a statement is likely in the paragraph just before, as a companion to the "that would suffice" language that applies to the resource server. For example, instead of just saying:
"The authorization server returns a permission ticket for the resource server to give to the client in its response."
...it could say:
"The authorization server returns a permission ticket for the resource server to give to the client in its response that represents what the resource server registered."
(worded slightly fuzzily to account for any future action taken on #152)
The text was updated successfully, but these errors were encountered: