It is a way of saying the AS doesn't need to return an error if scope is not 
included, though it has the option to return an error if it has no default 
scope.

However what the server may use as a default value us application specific.  
e.g. the client may have registered a default scope or scopes, or a default is 
documented as part of some API.

I think the goal is that the behaviour of the AS is in some way predictable to 
the client, while leaving it to the individual API to define the behaviour of 
scopes including what to do if you don't get an explicit one in the request.

John B.
On 2012-02-13, at 1:13 PM, Justin Richer wrote:

> In most cases, it will likely be a fixed value, but there's nothing 
> indicating that it can't be contextual. Especially in cases where you've got 
> public, confidential, and dynamically-registered clients all acting on the 
> same host, the default value will depend completely on what kind of client is 
> asking.
> 
> Really, this is a way of saying "scope is up to the AS", which it is, even if 
> the client asks for something else.
> 
>  -- Justin
> 
> On 02/12/2012 11:44 PM, Andrew Arnott wrote:
>> 
>> From section 3.3 (draft 23):
>> If the client omits the scope parameter when requesting authorization, the 
>> authorization server MUST either process the request using a pre-defined 
>> default value, or fail the request indicating an invalid scope. The 
>> authorization server SHOULD document its scope requirements and default 
>> value (if defined).
>> 
>> Is this saying that the pre-defined default value must be a FIXED value for 
>> all clients and all grants?  Or might the predefined default value actually 
>> be a derivation of the grant? (for example, by default the access token 
>> scope is simply the maximum scope allowed by the grant)
>> 
>> Thanks.
>> 
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death 
>> your right to say it." - S. G. Tallentyre
>> 
>> 
>> _______________________________________________
>> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to