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

Justin Richer <> Tue, 09 June 2015 16:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF3A91A8AB3; Tue, 9 Jun 2015 09:07:54 -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 FhYF0uMNirq6; Tue, 9 Jun 2015 09:07:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 054AC1A8AAE; Tue, 9 Jun 2015 09:07:50 -0700 (PDT)
X-AuditID: 12074425-f79076d000000db5-c3-55770f54cce5
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 D9.11.03509.45F07755; Tue, 9 Jun 2015 12:07:48 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t59G7lKd014867; Tue, 9 Jun 2015 12:07:47 -0400
Received: from [] ([]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t59G7e0I028655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2015 12:07:42 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4AEFC267-260D-4F00-BB82-D1BC392A3136"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer <>
In-Reply-To: <>
Date: Tue, 09 Jun 2015 09:07:37 -0700
Message-Id: <>
References: <>
To: Barry Leiba <>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsUixCmqrRvCXx5q8H66rMWhxZdYLc5uus1u sWJ5ucWLxTuZLWb8mchscXvuSjaLk29fsTmwe7Ss6mX2WLLkJ1MAUxSXTUpqTmZZapG+XQJX xtyfU9kL7qtXXDx0m7WB8ZBCFyMnh4SAicSqM+vYIWwxiQv31rN1MXJxCAksZpJY9nMOE4Sz gVHifONyVghnNZNET8MysBZhgXSJ4w/fsoHYvAJ6Eo+ePmYHKWIWmMIo8fDEPSaIuVISTa+P MYLYbAKqEtPXtADFOTg4BRwlvs0IBwmzCKhIrPn5gwWi9xejxJMjO9khhlpJfJzbDNYrJOAg cek9SBEnh4iApsTzz1PA5kgIyEp83So3gVFwFpIzZiE7AyTBLKAtsWzha2YIW1Nif/dyFghb XmL72zlQcUuJxTNvQMVtJW71LYDqtZN4NG0R6wJGjlWMsim5Vbq5iZk5xanJusXJiXl5qUW6 Fnq5mSV6qSmlmxhB0cbuorqDccIhpUOMAhyMSjy8JxTKQoVYE8uKK3MPMUpyMCmJ8przlIcK 8SXlp1RmJBZnxBeV5qQWH2JUAdr1aMPqC4xSLHn5ealKIrx7nwC18qYkVlalFuXDlElzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4M3lA1ogWJSanlqRlplTgpBm4uA8xCjBwQM0/Ccv UA1vcUFibnFmOkT+FKOilDjvNZCEAEgiozQPrheWJF8xigO9JcyrBLKCB5hg4bpfAQ1mAhq8 kBlscEkiQkqqgbGivi028mk5o2d5/BLvA/NXNy9hWN7xT7ss4pnebyWuOaoZBn77q5+KyLar 39Pirsy6X/fucK/fsWkaziLxijxLIgx1mneFHvnQqL1vU3LAjw13CyX5TORXPLuzfI79G8Hq eSGLXlnv6rFykopsa3u3417XzMBGobSKZrElBwJrZVIeKUZYKrEUZyQaajEXFScCACBXRIlt AwAA
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: Tue, 09 Jun 2015 16:07:54 -0000

Barry, thanks for the review. Responses inline.

> On Jun 8, 2015, at 5: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?

I’m fine with just calling it a protocol, I don’t want people to garden-path on it.

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

The gist is simple: It must be served over HTTPS, not HTTP.

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

GET is a deployment optimization that some servers will offer, and the OAuth client will tell the HTTP client which verb to use. The OAuth client might know through configuration (assuming a tighter coupling than defined by the interoperable protocol)

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

You are correct in your reading and that’s a better way to state that, thank you.

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

That’s a fair comment, I’ll change that.

Thank you,
 — Justin

> _______________________________________________
> OAuth mailing list