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

Remove reference to "user" in List Resource Descriptions #273

Closed
nynymike opened this Issue Jan 16, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@nynymike
Copy link

nynymike commented Jan 16, 2017

  • 2.2.5 List Resource Descriptions:
    "Lists all previously registered resource identifiers for this user using the GET method."

It's unclear how the RS would communicate which user's resources should be returned...

@jricher

This comment has been minimized.

Copy link

jricher commented Jan 16, 2017

The user represented by the PAT for which the resource server is registering resources.

@nynymike

This comment has been minimized.

Copy link
Author

nynymike commented Jan 16, 2017

Only in some use cases... what about M2M scenarios? Also, Resource Registration is supposed to be independent of UMA. So if you want to make that case, we need to more tightly bundle Resource Registration with UMA. I did a search of "user" in this spec, and the way it's used here is not clear from the previous text.

@jricher

This comment has been minimized.

Copy link

jricher commented Jan 16, 2017

In M2M there's still an owner of the PAT, which is effectively the RS itself. In these cases, the RS would probably just register everything on its own because there's only one "user", itself.

I've long argued that resource registration (as specified) is much more tightly bundled with core UMA than it claims to be, and this is just another example.

@xmlgrrl

This comment has been minimized.

Copy link

xmlgrrl commented Jan 18, 2017

(In M2M where there's a single RO, yes, the list would be of all resources controlled by that RO. I don't think there's a "probably" about it.)

The reason I asked Mike to submit this issue was precisely that RReg is supposed to be a more generic spec, and we've already done a bunch of work to excise mentions of overt resource-owner context that gets bound to the registration of the resources, but this is a place where it snuck in (because it said "user"). RReg doesn't have PATs, and the mechanism for establishing AS-RS trust is flexible as noted in the intro to Sec 2 (up to rev 04 as of this writing):

"The endpoint for this API SHOULD require some form of authentication to access this endpoint, such as Client Authentication as described in [RFC6749] or a separate OAuth access token. The methods of managing and validating these authentication credentials are out of scope of this specification."

We could say more here about how the AS-RS trust model and the ability to recognize resource owner context within that trust model determines the behavior of the operations. (It's not just List that's affected, it's actually all of them.) If OAuth is used for protection, then the AS-RS trust is formed in an in-band manner and the necessary context is passed in the authorization header. If any other method is used for protection, then trust is formed in some manner that is not in-band, and the necessary context has to be established in some other way. UMA happens to use the former.

@mrpotes

This comment has been minimized.

Copy link

mrpotes commented Jan 23, 2017

@jricher's suggestion seems correct to me, but just needs abstracting to exclude UMA specifics, e.g. ... for the entity identified by the authentication referenced in Sec 2.

However, given section 2 only specifies a SHOULD, what are we expecting the RS to return from this endpoint in the event that it hasn't implemented some form of authentication?

@xmlgrrl

This comment has been minimized.

Copy link

xmlgrrl commented Mar 2, 2017

From UMA telecon 2017-03-02: There is a shallow way to treat this issue, and a deep way, and maybe a medium way.

  1. A shallow way is s/user/resource owner/. This gets rid of the jarring impact of seeing "user", considering that Mike has implemented RReg for an OAuth-based API protection use case (as in the first bullet of the RReg Intro), using the client credentials grant.
  2. Another shallow way (in addition to #1, presumably) might be to require OAuth for protecting the RReg endpoint, which requires providing a resource owner context.
  3. The deep way might be something like absorbing the entire RReg spec into the UMA Core spec, if we think it's truly incompatible with OAuth and OpenID Connect use cases generally.
  4. A medium way might be refactoring the RReg spec to draw the dividing line in a different place, such as having RReg merely provide the bare bones of the API, and having Core provide extension properties to do all the "policy-setting-relevant" work, such as the name, icon_uri, and description fields. This would lengthen Core kind of significantly, but keep an interesting RReg module.

Eve and Mike aren't crazy about no. 4 because it's invasive and really lengthens Core, and it isn't proven yet that RReg as it stands isn't relevant to all three of the technologies or others yet to come.

xmlgrrl added a commit that referenced this issue Mar 8, 2017

@xmlgrrl

This comment has been minimized.

Copy link

xmlgrrl commented Mar 13, 2017

Let's close this issue in favor of one that's written more in line with the real challenge at stake. I've just created #290. We've agreed to keep an eye on it as we gather feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.