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

"Barry Leiba" <barryleiba@computer.org> Mon, 08 June 2015 12:36 UTC

Return-Path: <barryleiba@computer.org>
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 1F4001A3BA3; Mon, 8 Jun 2015 05:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6o7VrPPxt8xM; Mon, 8 Jun 2015 05:36:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 732CE1A1EF2; Mon, 8 Jun 2015 05:36:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba <barryleiba@computer.org>
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: <20150608123617.6617.42932.idtracker@ietfa.amsl.com>
Date: Mon, 08 Jun 2015 05:36:17 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/MckIrO_EAyBXaNLfDX3UnYqFDVE>
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] Barry Leiba'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: Mon, 08 Jun 2015 12:36:19 -0000

Barry Leiba 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:


All of the stuff below is fairly minor and isn't blocking... but I would
like to discuss with you any items that you disagree with, please.

-- Section 1 --

   This specification defines an interoperable web API

How is that different from, "This specification defines an API"?  I don't
know why a web API differs from any other kind of API, nor what makes an
API particularly interoperable.  That said, this document appears not to
be defining an API at all... it seems to be defining a protocol.  Why do
you think it's an API?

-- Section 2 --

   The introspection endpoint MUST be protected by a transport-layer
   security mechanism as described in Section 4.

I know what it means for a communication path to be protected by TLS, but
I don't know what it means for an endpoint to be.  Can you explain that?

-- Section 2.1 --
The server MUST support POST, and MAY support GET.  What's the value in
that?  I don't see any way for a client (I mean HTTP client, not Oauth
client, here) to know, so all clients will have to send POST to be sure
it will work.  Are you really expecting to have clients that want to ask
this, but that can't send POST?  Given that you call out privacy concerns
with GET, I don't see why it's there at all.

-- Section 2.2 --
The definition of "scope" is odd, because I think you mean that it's a
single JSON string, and that the content of the string is a
space-separated list of scope values... it's not actually multiple JSON
strings, right?

-- Section 3.1 --
I'd REALLY like to see us stop trying to tell IANA how to handle review
by designated experts.  This should be re-cast as instructions to the DE
(to make sure that the mailing list is consulted), and IANA should be
left to handle the expert review with their existing process, which works

While we're at it, it would be nice to have some further instruction to
the DEs about what they should be looking at when deciding whether to
approve a request.  There's some very minimal instruction under "name" in
the template, but that's all.  Is there nothing more to say?

-- References --
Because many of the items in the response are defined in RFC 7519, I
think that RFC should be a normative reference.