Subject: [OAUTH-WG] Proposed change to Introspection

From: Justin Richer <[email-masked]>
Date: Thu, 11 Jun 2015 14:54:02 -0700

In the IESG review, several reviewers have brought up an issue with current normative language:

   The protected resource calls the introspection endpoint using an HTTP
   POST [RFC7231 <https://tools.ietf.org/html/rfc7231>] request with parameters sent as "application/x-www-
   form-urlencoded" data as defined in [W3C.REC-html5-20141028 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-09#ref-W3C.REC-html5-20141028>].  The
   authorization server MAY allow an HTTP GET [RFC7231 <https://tools.ietf.org/html/rfc7231>] request with
   parameters passed in the query string as defined in
   [W3C.REC-html5-20141028 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-09#ref-W3C.REC-html5-20141028>]. 
The contention is that by saying that the server MAY support GET in addition to POST, no client can actually count on there being GET capability. 

My proposed fix was to remove the “MAY allow GET” sentence above. The spec would require POST support and remain silent on other methods. This would implicitly mean that you could implement GET as well (and most implementations have), but it’s implicitly outside the scope of the spec. We would keep the discussion of the GET method in the security considerations, as some implementors might want to disable GET for those reasons.

Since this change doesn’t really effectively change the deployment profile of the document, it’s my view that this doesn’t need another WGLC if we adopt this change. If you can think of a reason for us to *NOT* make this change, please post your concerns and suggested fix to the list.

Thanks,
 — Justin