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

Kathleen Moriarty <> Mon, 08 June 2015 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 482DE1A7026; Mon, 8 Jun 2015 06:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DCtgEUVejDhV; Mon, 8 Jun 2015 06:55:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4B101A8823; Mon, 8 Jun 2015 06:55:37 -0700 (PDT)
Received: by wiga1 with SMTP id a1so87397905wig.0; Mon, 08 Jun 2015 06:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Fl4JlOXWiy+4K3+mgwobzyF8DN+wrWJ6xNkQ/hzgYs=; b=g85D+MEH+Cxs0/qc+YA35XiL05Kyt8iraZXfC6Jd1hkUwRwYoWo/QJM8aB/BhIuId3 R8ygy2+PXsiq9C62ZqU6LNr9e78lZ7pGW+wzR3I3StOWC3yRFcWxu8erHQYu4G/3GrUx +M+vOD1Jm9Ht720Dum5xiNfn75My/nFi2Hodolevqj09C0iTBo4HhBXV7HSWsmEmErSH fRqwUFmVEDU7eO1D0daeVVUnulVcyBtELvn9UntLSS6nwDicDpjSd0yJw80ACvOdzo0w i84R1kcUKzZHBbq3shHOg/cBLzevJmMOTq/5JDIfNT10X1rs6CACYvxzm0Ig43zcp9KV mfgw==
MIME-Version: 1.0
X-Received: by with SMTP id y8mr33155685wja.86.1433771736369; Mon, 08 Jun 2015 06:55:36 -0700 (PDT)
Received: by with HTTP; Mon, 8 Jun 2015 06:55:36 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 08 Jun 2015 09:55:36 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: Barry Leiba <>
Content-Type: multipart/alternative; boundary="047d7b5d9889090dc3051801ffe9"
Archived-At: <>
Cc:,, "" <>,, The IESG <>,
Subject: Re: [OAUTH-WG] Barry Leiba'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: Mon, 08 Jun 2015 13:55:46 -0000

Hi Barry,

Thanks very much for your detailed review.  I have one comment inline.

On Mon, Jun 8, 2015 at 8:36 AM, Barry Leiba <> wrote:

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

OAuth and JOSE have been using mailing lists where several DEs are on the
list and others can join.  These lists are separate from the WG mailing
list.  DEs are names with IANA, but the spec review happens on that list,
which is open.  This practice pre-date me as an AD.  I don't see what's
wrong with it as it separates out the requests from the WG mailing list,
but is still open and transparent.  Changing it now would alter how this
spec works and would make it different from the other OAuth specs, which
could be confusing.

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

I agree with this advice.


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


Best regards,