I'm glad I managed to prompt some discussion on the topic! In order to avoid responding to several individual messages in this thread, I'll compile points:
Use cases: The request was for use cases where signatures a la OAuth 1.0a might be required. I've tried to provide some, along with reasoning on how to identify use cases based on an understanding of how requiring SSL/TLS results in certain performance changes. I think the fact that there are a lot of use cases where signature schemes don't provide an advantage in performance don't take anything away from the argument that there are use cases where performance is worse. There may be other use cases that have nothing to do with performance, but we needed to get the topic on the table. Amortization or priming of the SSL/TLS connection: Priming and amortization are possible in a lot of circumstances though I've tried to pick some where it is difficult. Whether priming is desirable at all is another question. Is it really more developer friendly to have to use this trick than to use an OAuth library to sign your requests? Regardless, priming does not address use cases affected by the symmetric/private encryption penalty (which is apparently significant), or use cases where it is difficult to prime a connection or amortize the connection penalty over a large number of requests. RSA vs. HMAC: I really have no idea. On the other hand, Google is the only existing provider I am aware of that supports the RSA method, and Google quickly adopted HMAC as well. If the only use-case for the RSA method is to establish similar security properties to those provided by SSL/TLS with no performance or implementation advantage, then we should get rid of it. I think we already had this discussion and I have no personal interest in rehashing it. Signing (a la OAuth 1.0a) over an insecure connection is as good as or better than bearer-tokens over an insecure connection: I'll stand by this, especially after reviewing RFC 2617 (1), which seems to reinforce the position. Request hijacking: I actually significantly understated the protection against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a provides. In the worst case, a MITM can hijack a request but cannot change the request method, URL, query parameters, nonce, or timestamp. In the best case (a single-part form-encoded request body or a request consisting only of query parameters), the MITM cannot modify the request at all because it is fully signed. It is not true, as Dick contends, that a MITM who has captured a signed OAuth 1.0a request can use a signed access token as if it were a bearer token. It is far more limited in the worst case, and useless in the best case. To be clear: I want a bearer-token over SSL/TLS method in OAuth. I'm not arguing against that. I'm simply trying to establish that there is a use-case for a signature method. Thanks, Ethan (1) http://www.apps.ietf.org/rfc/rfc2617.html#sec-4 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
