Re: [OAUTH-WG] Requesting mutliple scope, but user authorizes not all
As Eran pointed out, the way you've formatted your scope request, you've only specified one scope and I'd guess to keep things simple and consistent can either be approved or denied. I don't have a spec reference about what happens when the user doesn't approve but I assume the response is sent to the callback url. Now, what I heard in your email was a question about best-practices. The developer requests a number of scopes and the approval page on the authorization server allows the user to select which of those they approve and reject the rest. I don't think this is the the way that this sort of thing has been implemented for the most part. It's an all-or-none deal on most of the larger providers these days. Microsoft initially had a multiple choice UI for OAuth1 but I think they've abandoned that. So the real question is: how do you make sure the developer sends exactly what the user is prepared to approve to the AS, instead of allowing downscoping during the approval step. The common way this works out is either the developer knows they only need certain scopes for their application and they're relatively static or it's a selective disclosure system like you've described and the user needs to pick what they're going to approve on the developer's site before any browser redirects are done and those pre-filtered choices are sent to the AS. hope this helps. davep On Fri, Nov 26, 2010 at 12:41 AM, Martin Ley wrote: > Dear list, > > perhaps I've overread it in the specification or it was not explicit about > my required scenario: > > > The Web-Server-Flow is used. An application requests data about the user. > The scopes are dateofbirth,isover18,address. Now the user is forwarded to > the authorization server to identify and authenticate and give permissions > to the applications. The user decides to give only permission for the > isover18 scope but not dateofbirth and address. > > How would the application be notified about the granted scopes and the not > granted scopes? > > Best regards > > Martin > > > -- > tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH > Geschäftsführer: Boris Esser, Elmar Geese > HRB AG Bonn 5168 - USt-ID (VAT): DE122264941 > > Heilsbachstraße 24, 53123 Bonn, Telefon: +49 228 52675-0 > Thiemannstraße 36a, 12059 Berlin, Telefon: +49 30 5682943-30 > Internet: http://www.tarent.de/ Telefax: +49 228 52675-25 > > ___ > 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
Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10
-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 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
Re: [OAUTH-WG] Flowchart for legs of OAuth
Hi Phil, I actually think this rephrasing of the rule of thumb is not really helpful based on how the word "legs" has been used in my experience of discussing and teaching OAuth. I actually tried to be pretty explicit about this topic in a talk I did at Google I/O last year because we have lots of questions about 2 versus 3 legged OAuth since the launch of the Google Apps Marketplace. http://www.youtube.com/watch?v=0L_dEOjhADQ. I speak about 17mins in. We have traditionally used the terms two legged OAuth and three legged OAuth to describe the trust relationships involved in the grant. I think your interpretation is very different and not a common way to use the terms 'legs' in relation to OAuth and will simply confuse people. 2LO involves a client authenticating itself to a server. 3LO involves those two previous actors, plus a user/resource owner who delegates permissions to the client. In everyday use, 2LO is 'server to server' auth with out of band permissions and user identity and 3LO involves an individual grant where the user's grant is identified by a token given to the client and passed to the server on access. Another way to look at it is 2LO is just HTTP request signing. davep On Mon, Feb 21, 2011 at 4:45 PM, Phil Hunt wrote: > FYI. I published a blog post with a flow-chart explaining the legs of OAuth. > http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html > > Please let me know if any corrections should be made, or for that matter, any > improvements! > > Phil > phil.h...@oracle.com > > > > > ___ > 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
