Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt

[George Fletcher <[e-mail]>]

I definitely like the idea of an Errors section that normatively defines 
error responses.

Thanks,
George

On 1/11/13 1:04 PM, Richer, Justin P. wrote:
> It should follow the 6749 Token Endpoint error responses for bad 
> client credentials. That's what this text at the end of 2.3 is 
> supposed to mean:
>
>     If the client credentials are invalid or there is another error, the
>     Authorization Server responds with the appropriate error response
>     from the OAuth2 Core.
> Looking at it now, it's completely non-normative and stuffed into the 
> examples section, which is probably not the best way to describe it.
>
> There was some confusion about the {valid: false} response as well, so 
> now I'm thinking that should be pulled into an "Errors" section, perhaps?
>
>  -- Justin
>
> On Jan 11, 2013, at 12:38 PM, George Fletcher <[e-mail] 
> <mailto:[e-mail]>>
>  wrote:
>
>> Additional feedback on the introspection endpoint.
>>
>> What is the expected error response if the introspection endpoint is 
>> using client credentials as recommended in section 2.1
>> The endpoint SHOULD also require some form of authentication to
>>     access this endpoint, such as the Client Authentication as described
>>     in OAuth 2 Core Specification [RFC6749  <http://tools.ietf.org/html/rfc6749>] or a separate OAuth2 Access
>>     Token.
>> and the client credentials are invalid. It doesn't seem correct to 
>> return an HTTP 200 with a body of { "valid: false } as the endpoint 
>> probably never even tried to validate the token parameter.
>>
>> I can see a couple of options...
>>
>> 1. Follow the RFC 6749 /token endpoint and return an HTTP 40X 
>> response with the error described in JSON in the body of the response.
>>
>> 2. Follow RFC 6750 and return a WWW-Authenticate Response header that 
>> contains the error and optionally error_description.
>>
>> Thanks,
>> George
>>
>