Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10

[David Primmer <[e-mail]>]

-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-mail]> 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
> [phone]                         http://www.twitter.com/xmlgrrl
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>