-1 to separate parameters. I'd imagine every provider has the same issues as the ones you point out, however I don't think we should take another step toward complexity in this area. We've all managed to squeeze our resource access control semantics down into a single value and it usually requires some form of specific (I'd rather not call it "proprietary") formatting. I don't think there's any problem with defining what works for you there. And, I don't think we to get into XACML-like complexity around this 'scope' feature. It's a slippery scope slope.
davep On Sat, Dec 4, 2010 at 7:42 PM, Eve Maler <e...@xmlgrrl.com> wrote: > A comment on Mike's comment on the idea of a "resource" parameter... > > On 24 Nov 2010, at 11:31 PM, Eran Hammer-Lahav wrote: > >> Thanks Mike! Comments inline. >> >>> Normative Issues >>> >>> 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1 "Scope" parameter should be >>> paired with >>> complimentary "resource" parameter >> >> I am more inclined to drop 'scope' than to include 'resource'. Scope as >> currently defined can easily accommodate resource - we specifically chose >> space-delimited to allow URI values. If you want a new parameter, *you* will >> have to build consensus. Not wearing my editor hat, I'm -1. > > Over in UMA-land we've had to solve for this because our use cases anticipate > protecting arbitrary resources, not just singular APIs, and because our > loosely coupled resource server and authorization server components need to > communicate about this stuff in an organized fashion. > > After many months of discussion, as well as UX and implementation work by > various participants, in the last week we finally got consensus around having > two parts (resource sets and actions, the latter being a close analogue to > today's OAuth scopes) rather than a single flat scope namespace. The > degenerate case could be very much like today's common practice, but we > believe it handles a lot more use cases. > > There's still work to do to propagate information in this two-part form > throughout the protocol flow (which is what Mike was directly suggesting), > but at least we now have a conceptual foundation for doing that. If there is > consensus here for adding a parameter, it would make UMA's life easier as we > wouldn't have to invent anything weird and nonstandard. :-) > > See the "Resource Registration" spec link from our Working Drafts page for > more info; if there's sufficient interest, we could contribute it as an IETF > I-D soonish: > > http://kantarainitiative.org/confluence/display/uma/Working+Drafts > > Eve > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
