The underlying issue is that there was a decision not to in any way standardize values for scope.
I agreed this was reasonable since the underlying resource APIs are likely to be very specific requiring some degree of prior knowledge by the client app developer. Thus the resource server OAuth infrastructure is free to decide what are and are not acceptable values including missing or null values for scope. I think the specification is acceptable as it is. I note that other specifications that layer on top of OAuth2 such as OpenID Connect may choose to strictly define acceptable values for scope. This type of layering works well in my opinion. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-01-10, at 10:56 AM, SM wrote: > At 09:19 10-01-2012, William Mills wrote: >> That does clear it up! If the implementation returns a proper error when >> the scope is omitted then it will be in conformance. Sending an error >> result for the empty scope is valid. > > Yes. > > It is not possible to get a clear view of the specs if the discussion about > "ambiguity" relies on the meaning of the word "OPTIONAL" only. If there is a > problem, then clarifying text could be used to fix it instead of changing the > requirements. > > Regards, > -sm > _______________________________________________ > 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
