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

Reply via email to