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