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 <barryle...@computer.org> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
