Stop
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hm... how so? If a server is able to specify in advance which set of
scopes it will honor (which may or may not be related to what the client
specified in the registration) I can see that being useful. I don’t see a
requirement for a linkage between the client’s request and the server’s
response.
I agree that we shouldn't try to "solve" scope in registration. I think it
makes the most sense for registration to be as hands-off about scope as core
OAuth is.
-- Justin
On Apr 18, 2013, at 12:18 PM, Phil Hunt
mailto:phil.h...@oracle.com>> wrote:
There are a number of cases that all demand
There are a number of cases that all demand a more parsable scope.
One of the cases is multi resource scopes.
Would it not be reasonable to develop another draft that defines a simple json
structure that allows different uris to be matched with specific scope values?
I also wonder if registra
I’m unconvinced, Mike. Obviously you’re right about the looseness of
OAuth2 scope specification, but this is a very specific semantic of what
happens when you register, and I don’t think we’re bound by history here.
If we can’t safely say anything about what the list of scopes means, then
I'm with
On the server-to-client side, what does “registered to use” mean? Does it
mean that the client should assume that any scopes not on the list WILL not
be granted, MAY not be granted or what? Is this already covered
elsewhere? -T
On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones wrote:
> Thanks,
