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

"Ben Campbell" <ben@nostrum.com> Wed, 10 June 2015 00:24 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66A61A9030; Tue, 9 Jun 2015 17:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RDCvbl-nZMP; Tue, 9 Jun 2015 17:24:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5B21A902B; Tue, 9 Jun 2015 17:24:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150610002416.13636.71337.idtracker@ietfa.amsl.com>
Date: Tue, 09 Jun 2015 17:24:16 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/z-Qf7r9_KClXi6P1XO5KwOm5L_Q>
X-Mailman-Approved-At: Wed, 10 Jun 2015 06:21:52 -0700
Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 10 Jun 2015 00:24:22 -0000

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.)

-- 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?

-- 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.

-- 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.

-- 4, bullet list:


It seems odd to have 2119 keywords in a "For instance" section.

--4, 6th paragraph from end

The reference to [TLS.BCP] should probably be normative.

-- 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.