Use of "implicit resource set"

[findthomas]

Should it be possible to have an "implicit resource set" somehow that (in syntactic-sugar fashion) allows permissions to be passed around much as scopes already are passed around in plain OAuth? (Someone want to take this AI?)

[Previously #33]

[xmlgrrl]

A recent thread on the OAuth list, regarding "OPTIONAL" scopes, may be interesting to consider in this context: http://www.ietf.org/mail-archive/web/oauth/current/msg08190.html

[xmlgrrl]

A solution for this was essayed in the new oauth-resource-set-reg-00 module, but the group rejected it today. There doesn't seem to be a good solution yet.

[xmlgrrl]

We discussed this pretty heavily in the UMA telecon 2014-12-18 timeframe, but there's little sentiment for handling a literal implicit resource set. It's now possible to register a single (named) resource set and associate string-based OAuth-style scopes with it. It's also possible to use token introspection and off-the-shelf JWTs with the result. So there's probably little need to do anything else for the moment, since the "cost" of naming the resource set is pretty low, and even OAuth users may find it valuable to name (multiple) resource sets eventually, even without using UMA (e.g. scopes for photos vs. photo albums etc.). It's backlogged for now; we can consider whether to close it at our leisure later on.

[aleclaws]

The 'resource definition' draft is in the spirit of this ticket, there is also some relation to #288

I interpret this issue as allowing the AS to have well know resource_type/scope pairs such that the permission in a UMA ticket can reference this 'implicit' resource instead of a specific registered resource id. It also enables AS-first flows where the client can request this resource/type scopes, and the RqP, during claims gathering, could select the specific RS that can serve the 'implicit' resource

ps. I don't have the full UMA 1 history, so let me know if this is off the mark

[xmlgrrl]

The spirit was that we were looking to reduce the friction between UMA and OAuth. Reducing friction to the point of enabling AS-first flows would go a pretty long way. :-) And working within an extension (which I think resource definition is, vs. a "mere" profile?) already allows some freedom to optimize things in this direction (and in the general direction of removing chattiness and so on).