Skip to content
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

Closed
xmlgrrl opened this issue Jul 20, 2015 · 4 comments
Labels
core Related to (original UMA1) core spec scope; may use obsolete language critical V1.0.1
Milestone

Comments

@xmlgrrl
Copy link

xmlgrrl commented Jul 20, 2015

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)

@xmlgrrl xmlgrrl added the core Related to (original UMA1) core spec scope; may use obsolete language label Jul 20, 2015
@mmachulak
Copy link

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.

@xmlgrrl
Copy link
Author

xmlgrrl commented Jul 20, 2015

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.

@mmachulak
Copy link

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.

@xmlgrrl xmlgrrl added this to the V1.0.1 milestone Jul 31, 2015
@xmlgrrl xmlgrrl added the V1.0.1 label Aug 13, 2015
xmlgrrl added a commit that referenced this issue Aug 20, 2015
Fixed the description of the ticket matching what was registered in Sec
3.2. Also fixed the “incomplete satisfaction of policies” description
and moved it to Sec 3.4.1.
xmlgrrl added a commit that referenced this issue Aug 27, 2015
This is a small tweak to reapply one fix that didn’t get made in the
last “fixed commit”.
mmachulak added a commit that referenced this issue Aug 27, 2015
* commit '09978db53e5df5273060c1743b3f2a8e70ed2bb3':
  Small fix to re-complete #170
  Small fix to re-complete #175
@xmlgrrl
Copy link
Author

xmlgrrl commented Aug 28, 2015

Proposed, discussed, and reviewed in UMA telecon 2015-08-27. We can close this.

@xmlgrrl xmlgrrl closed this as completed Aug 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Related to (original UMA1) core spec scope; may use obsolete language critical V1.0.1
Projects
None yet
Development

No branches or pull requests

2 participants