Just as a matter of clarification about the downscope language in the spec:
The downscoping capability here is intended mostly for getting special-use tokens, for things like redelegation to other apps. So say I grant access to AppA with scope "read write", and AppA gets a refresh and access token. AppA can then present its refresh token to the token endpoint and request an access token with scope "read" in order to get a downscoped token (in this example, a read-only token), either to limit the vulnerabilities of tokens in flight or to hand to another app. The key is that AppA's request for a downscoped token with their previously-verified grant will not reprompt the user. -- Justin On Wed, 2010-12-01 at 16:17 -0500, David Primmer wrote: > 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
