Re: [OAUTH-WG] Requesting mutliple scope, but user authorizes not all

[Justin Richer <[e-mail]>]

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 <[e-mail]> 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: [phone]
> > Thiemannstraße 36a, 12059 Berlin, Telefon: [phone]
> > Internet: http://www.tarent.de/   Telefax: [phone]
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth