Re: [OAUTH-WG] Clarification about compatibility between rfc6750 and rfc7662

[Justin Richer <[e-mail]>]

These specs cover two different connections: 6750 is client to RS, 7662 
is RS to AS.

When the authorization server and the resource server are the same box, 
it will know exactly why the token isn't any good and it can react 
accordingly. The client doesn't actually care: note that the error 
response in the example is descriptive text and not a value to be parsed 
and acted upon.

In the case where they're a separate box (which is what introspection is 
set up for), the RS might not be allowed to know the details about the 
token not being good, and in any event it doesn't change how the RS 
responds to that situation.

So to use them together, you would respond with "active: false" from 
introspection and return a WWW-Authenticate header with "invalid_token" 
from the resource to the client, no description field needed.

  -- Justin

On 2/13/2017 4:59 PM, Maduranga Siriwardena wrote:
> Hi All,
>
> While going through [1] and [2] I noticed a small contradiction 
> between the standards.
>
> Section 3 (The WWW-Authenticate Response Header Field) of [1] provides 
> a example with WWW-Authenticate header description error description 
> with "The access token expired".
>
> This error description should have been obtained from the response of 
> introspection request sent to the authorization server. But according 
> the section 2.2 (Introspection Response) of [2], it is not recommended 
> to include any additional information about an inactive token, 
> including why the token is inactive.
>
> So how these scenarios match with each other?
>
> [1] https://tools.ietf.org/html/rfc6750 
> <https://tools.ietf.org/html/rfc6750>
> [2] https://tools.ietf.org/html/rfc7662 
> <https://tools.ietf.org/html/rfc7662>
>
> Thanks,
> -- 
> Maduranga Siriwardena
> Software Engineer
> WSO2 Inc.
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth