Sure, I don't care about the exact mechanism - although "realm" and "scope" don't seem equivalent concepts.
Allen - I don't think a redirect is what we want, since the Protected Resource is typically server-to-server, or if done in a browser then it's not in a user-visible screen. On Apr 1, 2010, at 9:25 PM, Eran Hammer-Lahav wrote: > > > > 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? >> > > How is this any better/different than plain old 401 with realm='something'. > Why not have the client request a token capable of accessing the realm > specified? > > Before we go and invent a new mechanism that has exactly the same limited > capabilities, we should see if the existing one can be reused or improved > upon. > > EHL > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
