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

[Justin Richer <[e-mail]>]

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 <[e-mail]> wrote:
> 
>>> 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?
>> 
>> 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