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