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

[Justin Richer <[e-mail]>]

> On Jun 9, 2015, at 9:57 AM, Barry Leiba <[e-mail]> wrote:
> 
> Hi, Justin.  Thanks for the response and discussion.
> 
>>> -- 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.
> 
> 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
> 
>>> -- 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)
> 
> 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


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