401 seems more semantically correct, but I'm sure Eran knows the true answer. :)
+1 to this idea though. Helps client dynamically authorize users if it turns out they didn't ask for the right scope. On Thu, Apr 1, 2010 at 9:21 PM, Allen Tom <a...@yahoo-inc.com> wrote: > +1 > > How about if the Protected Resource returns an HTTP 302 redirect to the Auth > URL? The scope information can be encoded in the URL. > > Allen > > > > On 4/1/10 9:07 PM, "Luke Shepard" <lshep...@facebook.com> wrote: > > > On Apr 1, 2010, at 6:59 PM, Peter Saint-Andre wrote: > > If that's true, then how does the Authorization Server know what scope > is appropriate at the Protected Resource? Does inclusion of the scope > parameter require a 1:1 mapping between AS and PR, or at least > communication between AS and PR? > > My preferred way of handling this is to have the Protected Resource throw a > 403 Forbidden error, with an error message that specifies the scope needed - > e.g., "oauth_scope_required=photo_read". > > So an app that tries to access a protected resource should be able to > programatically take the scope in the error message and then construct an > OAuth authorization request to get that permission from the user. Even if > the scope is totally opaque, it should still be possible for a library to > handle them in this way. > > I believe David or Eran were thinking of writing this into the spec? > > ________________________________ > _______________________________________________ > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
