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

From: "Barry Leiba" <[email-masked]>
Date: Mon, 08 Jun 2015 05:36:17 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

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

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.

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 8 Jun 2015 09:55:36 -0400

Hi Barry,

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

> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

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.

> the template, but that's all.  Is there nothing more to say?

I agree with this advice.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jun 2015 11:40:19 -0400

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

I'm not objecting to the mailing list.  I'm objecting to telling IANA
how to integrate the mailing list into its procedure, which is
different from what its procedure is.  IANA initiates expert review
when it receives a request, contacting the DE and tracking the
process.  This tells IANA to send people directly to the mailing list,
and only to deal with requests from the DE.

The fact that requests need to be discussed on the mailing list is
something that the DE should be dealing with as part of her review,
and that takes us out of the business of telling IANA how to initiate
and track expert review, and making Oauth reviews different from those
for other protocols.

Barry

---

From: Justin Richer <[email-masked]>
Date: Tue, 9 Jun 2015 09:07:37 -0700

Barry, thanks for the review. Responses inline.

> On Jun 8, 2015, at 5:36 AM, Barry Leiba <[email-masked]> wrote:
> 

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

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

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

> space-separated list of scope values... it's not actually multiple JSON

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

> think that RFC should be a normative reference.

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

Thank you,
 — Justin

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Jun 2015 17:57:17 +0100

Hi, Justin.  Thanks for the response and discussion.

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

Right; that's protecting the communication path.  So I suggest this
(and it's a minor point; I'm OK with no further discussion, whether
you agree with the change or not):

NEW
   The introspection communication path MUST be protected by a
   transport-layer security mechanism as described in Section 4.
END

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

Two things:

1. Why is GET an optimization?  It has privacy disadvantages, and I
don't see any advantages.

2. This "tight coupling" thing is something that I think weakens the
interoperability of the OAuth protocol in general, and I've never
liked it.  In this case, in particular, I don't see any advantage to
it, and I don't understand why it's useful to have an option that only
works if you have inside knowledge, for no benefit.

Why is it ever good to have clients that only work with certain
servers, when it's just as easy to make sure that all clients work
with all servers?

Barry

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Jun 2015 13:04:59 -0700

> On Jun 9, 2015, at 9:57 AM, Barry Leiba <[email-masked]> wrote:
> 

I can see your point here, and others have raised it as well. Part of the reason the GET option is there is that most (if not all) of the existing implementations of this protocol enable it anyway. Having thought about this a bit, I would be fine with simply saying that POST is required and remaining silent on other methods in the main section. We can keep the warnings against also allowing GET in the security considerations. Will that work?

 — Justin

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jun 2015 22:32:39 +0100

> I can see your point here, and others have raised it as well. Part of
> the reason the GET option is there is that most (if not all) of the
> existing implementations of this protocol enable it anyway. Having
> thought about this a bit, I would be fine with simply saying that POST
> is required and remaining silent on other methods in the main section.
> We can keep the warnings against also allowing GET in the security
> considerations. Will that work?

That will be of great excellence all 'round.  Thanks!

Barry

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Jun 2015 20:51:55 -0400

Barry,

I’ve uploaded a new draft that should address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-10>

Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt>

Hopefully this will be sufficient to clear the DISCUSS.

Please let me know if you have any further questions,
 — Justin

> On Jun 11, 2015, at 5:32 PM, Barry Leiba <[email-masked]> wrote:
>