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

Protocol assumes one resource per URL #162

jricher opened this issue Jul 15, 2015 · 3 comments


None yet
2 participants
Copy link

commented Jul 15, 2015

The UMA protocol assumes that there's only one resource per URL, but not all APIs are designed this way. Some use contextual information in the request outside of the URL to determine the kind of request being made. For instance, in OpenID Connect's UserInfo Endpoint, the scopes associated with the access token used to make the request to the endpoint determine which parts of a user's profile are returned. The email scope maps to the email and email_verified claims, etc. While this is a trivial example whose specific details could be hacked around, this type of multi-use endpoint isn't unheard of in more complex scenarios.

API designers are vanishingly unlikely to change their APIs to accommodate the quirks of a security protocol.

@xmlgrrl xmlgrrl added the core label Jul 22, 2015

@xmlgrrl xmlgrrl added the critical label Jul 30, 2015

@xmlgrrl xmlgrrl added this to the V1.0.1 milestone Jul 31, 2015


This comment has been minimized.

Copy link

commented Aug 15, 2015

Discussion on 2015-08-13: The constraint is that the RS must be able, based on the C's access attempt with no token and no other context, to distinguish the AS and RO that match the protected resource set. In practice, this likely means that the URI needs to be unique per resource set. Let's mention this constraint in a few places. E.g., in Core Sec 1.3.1 and Core Sec 2. And we also have to put it into RSR Sec 2 and Sec 2.2.

@xmlgrrl xmlgrrl added the V1.0.1 label Aug 15, 2015

xmlgrrl added a commit that referenced this issue Aug 23, 2015

Incorporated #144 from Maciej
This completes the incomplete claims-gathering flow design.

(It also seems to take out the note related to #161/#162 in Sec 1.3.1
that we are just re-discussing now. Intentional?)

This comment has been minimized.

Copy link

commented Aug 28, 2015

The solution for this issue is wrapped up with that for #161, so we can close this one.

@xmlgrrl xmlgrrl closed this Aug 28, 2015


This comment has been minimized.

Copy link

commented Sep 3, 2015

I would suggest adding the note text from 9495bf9 to §1.3.3. as well.

@xmlgrrl xmlgrrl reopened this Sep 5, 2015

xmlgrrl added a commit that referenced this issue Sep 8, 2015

Re-completed #162
Added the note to 1.3.3 as well.

@xmlgrrl xmlgrrl closed this Sep 9, 2015

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.