Subject: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection

From: [email-masked]
Date: Mon, 19 Oct 2015 15:56:59 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 7662

        Title:      OAuth 2.0 Token Introspection 
        Author:     J. Richer, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       October 2015
        Mailbox:    [email-masked]
        Pages:      17
        Characters: 36591
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-oauth-introspection-11.txt

        URL:        https://www.rfc-editor.org/info/rfc7662

        DOI:        http://dx.doi.org/10.17487/RFC7662

This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.

This document is a product of the Web Authorization Protocol Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Justin Richer <[email-masked]>
Date: Tue, 20 Oct 2015 12:32:50 -0400

Thank you to everyone who helped make token introspection into a real standard!

 — Justin

> On Oct 19, 2015, at 6:56 PM, [email-masked] wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Oct 2015 10:20:27 +0200

Thank you Justin for the hard work!

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Oct 2015 07:47:19 -0400

Yes, nice job!

Sent from my iPhone

> On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Vivek Biswas <[email-masked]>
Date: Wed, 21 Oct 2015 20:27:46 +0000 (UTC)

Yes indeed a nice job  !!!!.
I have one question on the RFC.
Not sure where I can submit request for comments. Hence, adding to this email thread

In the use-case mentioned belowThe following is a non-normative example response for a token that
   has been revoked or is otherwise invalid:

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
      "active": false
     }

Where the token is revoked or invalid, why not send a HTTP response code of 400
There are 2 benefits for the same.A. Just looking at the header, we know that token validation didn't went through. No need to look in the payload. This is especially very helpful in gateway design implementation.
B. You are further hiding from the user why the request failed and not letting him know if the token was processed by the server.
CheersVivek
   
      From: Kathleen Moriarty <[email-masked]>
 To: Hannes Tschofenig <[email-masked]> 
Cc: "<[email-masked]>" <[email-masked]> 
 Sent: Wednesday, October 21, 2015 4:47 AM
 Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection
   
Yes, nice job!

Sent from my iPhone

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Oct 2015 17:01:33 -0400

This was discussed extensively and is covered in the text of the RFC, but the summary is simple: the request isn’t a bad request (which is what 400 means). It’s a perfectly valid request, it’s just that the token you’re asking about might not be valid for some reason, or it might not be valid *for you*. Either way, you don’t actually want to divulge too much information about why the token is bad in a production environment or else you let attackers poke around and learn more about the system than they really need to know to function. As far as a protected resource is concerned, it likely doesn’t matter anyway. And an OAuth client isn’t going to be propagated that information, it’s just going to have to go get a new token. Since an OAuth client needs to be able to get a new token at a moment’s notice anyway, there’s not really anything useful in communicating it.

This is a similar approach to the Revocation spec (RFC 7009) which always returns 200 whether or not the token existed or was successfully revoked. In any event, the client needs to assume that the token was revoked and stop using it, and it’s up to the server to deal with the consequences of error conditions. 

Hope this helps,
 — Justin

> On Oct 21, 2015, at 4:27 PM, Vivek Biswas <[email-masked]> wrote:
> 
> In the use-case mentioned below
> The following is a non-normative example response for a token that
> There are 2 benefits for the same.
> A. Just looking at the header, we know that token validation didn't went through. No need to look in the payload. This is especially very helpful in gateway design implementation.
> 
> Cheers
> Vivek
> > On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >>> On Oct 19, 2015, at 6:56 PM, [email-masked] <mailto:[email-masked]> wrote:
> >>> 
> >>>      Mailbox:    [email-masked] <mailto:[email-masked]>
> >>>      Pages:      17
> >>>      Characters: 36591
> >>>      URL:        https://www.rfc-editor.org/info/rfc7662 <https://www.rfc-editor.org/info/rfc7662>
> >>> 
> >>>      DOI:        http://dx.doi.org/10.17487/RFC7662 <http://dx.doi.org/10.17487/RFC7662>
> >>> 
> >>> Internet Protocol Standards (https://www.rfc-editor.org/standards <https://www.rfc-editor.org/standards>) for the 
> >>> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
> >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist <https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist>
> >>> 
> >>> For searching the RFC series, see https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>
> >>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html <https://www.rfc-editor.org/rfc.html>
> >>> 
> >>> author of the RFC in question, or to [email-masked]. <mailto:[email-masked].>  Unless
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>