Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

Justin Richer <> Thu, 11 June 2015 22:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0E5591B3380; Thu, 11 Jun 2015 15:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EzrEn1pRlF8B; Thu, 11 Jun 2015 15:25:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E0131B337F; Thu, 11 Jun 2015 15:25:49 -0700 (PDT)
X-AuditID: 12074423-f79496d000000d43-cd-557a0aeba693
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 66.F3.03395.CEA0A755; Thu, 11 Jun 2015 18:25:48 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t5BMPkQd024789; Thu, 11 Jun 2015 18:25:47 -0400
Received: from [] ([]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t5BMPgjZ029679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 18:25:44 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Justin Richer <>
In-Reply-To: <>
Date: Thu, 11 Jun 2015 15:25:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Campbell <>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1n3DVRVqsPI5s8X8ztPsFmc33Wa3 WLG83OLF4p3MFjP+TGS2uD13JZvFybev2BzYPZYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSu jKata9gLHilWXNl2kK2BcZl0FyMHh4SAicSHx4ZdjJxAppjEhXvr2UBsIYHFTBJrt4p0MXIB 2RsZJab++sEC4axlkpj84TBYFbOAusSfeZeYQWxeAT2JR08fs4PYwgIZEh+evGICsdkEVCWm r2lhAlnGKeAk0bhBCiTMAhRe+f4xI8hMZoFfjBJPjuxkh5ipLbFs4WuomVYSG3sPMkJc5Cix bm8/WFxEQEniefNWFogHZCW+bpWbwCg4C8lFs5BcNAvJ1AWMzKsYZVNyq3RzEzNzilOTdYuT E/PyUot0zfRyM0v0UlNKNzGCgp3dRXkH45+DSocYBTgYlXh4K05UhAqxJpYVV+YeYpTkYFIS 5V39pTJUiC8pP6UyI7E4I76oNCe1+BCjBAezkgiv4S+gHG9KYmVValE+TEqag0VJnHfTD74Q IYH0xJLU7NTUgtQimKwMB4eSBO8yzqpQIcGi1PTUirTMnBKENBMHJ8hwHqDh7iA1vMUFibnF mekQ+VOMilLivNkgCQGQREZpHlwvLBm9YhQHekWYdxJIFQ8wkcF1vwIazAQ0eCFzOcjgkkSE lFQDI3t2TJQyy/V1J/n3a05u05tfmy3cK6Hxh7Vx1wL/tzMfc5y37eLm/brmffLjziWz1z03 yrL+kr8spfT5lX8Rr6yXXX42I0jUbwVjm/SXudw7H0rd7ImO6jyt23riT7uPbnLhjkoO4Tef /74/tsj51nemtxpn5baf4Sphf7/HRr7R67Ow/ER/OyWW4oxEQy3mouJEAGddh6YhAwAA
Archived-At: <>
Cc:,,,, The IESG <>, "<>" <>
Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jun 2015 22:25:52 -0000

Ben, thanks for your review. Comments inline.

> On Jun 9, 2015, at 5:24 PM, Ben Campbell <> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-oauth-introspection-09: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I concur with Alissa's discuss.  
> Additional comments:
> -- There is no reference to RFC 2119, but there seems to be lots of
> capitalized 2119 keywords. If those are intended to have the 2119
> meaning, please add the usual reference. (I assume that these are
> intended as 2119 keywords for the remainder of the review.)

This seems to be a bug in the xml2rfc template, I’ll fix that. 

> -- 2.1, first paragraph:
> If the server MAY support GET, how does a client know to use it? Would
> you expect them to try and fail?

Was brought on by Barry Lieba, my suggested fix is to say server MUST support POST, and remain silent on other verbs. Will that suffice?

> -- 3
> Is there a reason not to use a more standard IANA procedure? (I.e. let
> people request registrations to IANA, and have them forward the requests
> to the DE?)
> --3.1, under "Name"
> The MUST seems unnecessary, as that's the whole point of a registry.

I pulled the IANA language from other specs, I’ll defer the proper wording and structure of this to other experts.

> -- 4:
> The security considerations have a lot of restated 2119 keywords. If you
> want to reinforce those here, it would be better to do so with
> descriptive language, rather than having multiple occurrences of the same
> normative language.  Redundant normative language is error prone,
> especially for future updates.

Noted. We’re not trying to re-state normative requirements in multiple locations, so I’ll carefully read through this again to make sure we’re saying something new where we add another 2119 statement.

> -- 4, bullet list:
> It seems odd to have 2119 keywords in a "For instance" section.

This was at the request of WG members and I’m open to wording it better. People wanted the protected resources to be able to count on count on the AS doing at least some reasonable checks on the token’s state. We can't prescribe exact AS behavior because the nature of tokens is going to vary so wildly (some expire, some don’t). What we want to do is provide a set of common checks that servers need to do in the right circumstances, depending on the nature of their tokens. 

> --4, 6th paragraph from end
> The reference to [TLS.BCP] should probably be normative.

It’s a best current practice on deployment practice of a supporting protocol, I think informative is the right level here but I’ll defer to other expertise if there’s a better form.

> -- 4, last two paragraphs: 
> "An authorization server offering token introspection MUST be able to
> understand the token values being presented to it during this call." and
> "the authorization server MUST be able to decrypt and validate the token
> in order to access this information."
> These seem more like statements of fact than normative language.

This is a fair characterization of this section, we can change those to “needs to” or lowercase “must”.

 — Justin

> _______________________________________________
> OAuth mailing list