[OAUTH-WG] Proposed change to Introspection

Justin Richer <jricher@MIT.EDU> Thu, 11 June 2015 21:54 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 237B91B2C2F for <oauth@ietfa.amsl.com>; Thu, 11 Jun 2015 14:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0qQ60NWKTAkk for <oauth@ietfa.amsl.com>; Thu, 11 Jun 2015 14:54:08 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2781B31C1 for <oauth@ietf.org>; Thu, 11 Jun 2015 14:54:07 -0700 (PDT)
X-AuditID: 12074424-f79b06d000000cfd-10-557a037e3912
Received: from mailhub-auth-3.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AE.FA.03325.E730A755; Thu, 11 Jun 2015 17:54:07 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t5BLs6SG021093 for <oauth@ietf.org>; Thu, 11 Jun 2015 17:54:06 -0400
Received: from [] ([]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BLs4oe016231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 11 Jun 2015 17:54:06 -0400
From: Justin Richer <jricher@MIT.EDU>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3194CC63-15E1-4C31-A946-07F8CCB2248D"
Message-Id: <8EEEA252-29A1-443B-90BF-3B3A21F0619B@mit.edu>
Date: Thu, 11 Jun 2015 14:54:02 -0700
To: "<oauth@ietf.org>" <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrVvPXBVqsHMmk8XJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMWXvdvaC1SoVzS3PmBsYu+S7GDk5JARMJI7e280KYYtJXLi3 nq2LkYtDSGAxk8TnyR9YIJxjjBKPni5ihnAOMUn8aF3LAtLCJqAqMX/lLSYQm1kgQeL+wpds ILawgKZE84GlYHFeASuJ7kt/mUFsFqD6h2t+gtkiAuoSa87/hKrRA1rwmL2LkQPoDFmJr1vl JjDyzkIydRaSKoi4tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4 OTEvL7VI11wvN7NELzWldBMjKCjZXVR2MDYfUjrEKMDBqMTDW3GiIlSINbGsuDL3EKMkB5OS KO/qL5WhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4DX8B5XhTEiurUovyYVLSHCxK4rybfvCF CAmkJ5akZqemFqQWwWRlODiUJHi1mapChQSLUtNTK9Iyc0oQ0kwcnCDDeYCG/2cEquEtLkjM Lc5Mh8ifYlSUEud9ApIQAElklObB9cKSxitGcaBXhHnPgVTxABMOXPcroMFMQIMXMpeDDC5J REhJNTBOeXuirzLKuJv1k//TwqNdQi22hS4Xrp84IG649jhjVse92btsevY3rj+0eW6L7+bq P07c295HaJ45MWne+hs8CUH6s565Nq55NpGTt31SmD6T2+Li5XK2IaGOi4P5JouZe1zN+TJx wrI+gWBTB20eK/HvaVLLrJb9yzH4NtvwEVtRTEO45hElluKMREMt5qLiRADWLK4b9QIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Luk6QMnwRsA7dAPobCsbPg7ymps>
Subject: [OAUTH-WG] Proposed change to Introspection
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 21:54:10 -0000

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.

 — Justin