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

Confusing reference to RPT in Protection API context #225

Closed
andihindle opened this issue Sep 8, 2015 · 1 comment

Comments

@andihindle
Copy link

@andihindle andihindle commented Sep 8, 2015

In §1.3.1, we have the following wording:

Note: When a client attempts access to a presumptively protected resource without an RPT, the
resource server needs to derive the authorization server and resource set identifier associated with that
resource from some other aspect of the client's request. This effectively means that the resource
server’s API needs to be structured in such a way that the client's RPT-free request uniquely identifies
the resource set. In practice, this information likely needs to be passed through the URI, headers, or
body of the request.

This is confusing, because §1.3.1 is all about the Protection API and the 'Protect a Resource' flow, but the note is about RPT/AAT flow. If you are reading the spec from top-to-bottom, with no particular foreknowledge of the spec, then the potential relevance of the RPT is entirely unclear.

Suggest the following alternative wording (edits in bold):

Note: as described in Section 3.2, if a client attempts access to a presumptively protected resource
without an RPT, the resource service may need to register the requested permission with the protection
API at the authorization servers. In order to do this,
the resource server needs to derive the
authorization server and resource set identifier associated with that resource from some other aspect of
the client's request. This effectively means that the resource server’s API needs to be structured in
such a way that the client's RPT-free request uniquely identifies the resource set. In practice, this
information likely needs to be passed through the URI, headers, or body of the request.

@xmlgrrl

This comment has been minimized.

Copy link

@xmlgrrl xmlgrrl commented Sep 8, 2015

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion and conclusion:

"Andi’s new issue suggests seating the “presumptively protected resource” note more firmly into the Sec 1.3.1 context. Eve likes it so much that she suggests doing this with each of the instances.

Okay, let’s give her an editorial instruction to do so."

xmlgrrl added a commit that referenced this issue Sep 9, 2015
Customized each appearance in Core. This will take some review.
xmlgrrl added a commit that referenced this issue Sep 13, 2015
Added “client’s” to remove ambiguity per UMA telecon 2015-09-10.
@xmlgrrl xmlgrrl closed this Sep 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.