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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
