title: Isn't oauth_signature reinventing the SSL wheel?
body: <p>While using the twitter API, I came across the <code>oauth_signature</code> which is basically a hash of the (request body + request parameters + nonces/timestamps + a <code>consumer_secret</code>). The <code>consumer_secret</code> is known only to the application that is sending the request. </p>
  
  <p>In Twitter's case:</p>
  
  <ul>
  <li>all communication MUST happen over SSL.</li>
  <li>twitter issues the <code>consumer_secret</code> to each authorized application.</li>
  </ul>
  
  <p>Since the primary use of the <code>oauth_signature</code> is to prevent MITMs (i.e. no tits (tampering in transit) :), it seems to me that this particular use case could be solved via Mutual SSL</p>
  
  <ul>
  <li>Twitter, instead of issuing the <code>consumer_secret</code>, can issue SSL certificates for each application.</li>
  </ul>
  
  <p>While this idea of client ssl-certificates might seem like 1990s internet arcana, it was not successful largely because of the trouble in verifying the chain of trust for client certificates. That problem does not arise here because twitter would be the sole issuer AND verifier of the certificates. The drawback would be much more involved effort on Twitter's behalf to produce the initial application/client ssl certificates, but the payoff would be in the simplicity of the REST API, which can rest on the guarantee that the client is who he says he is.</p>
  
  <p>Note that twitter is just an example in this case. AFAIK, most other oauth implementors use a similar strategy, and the points here apply to any large scale OAuth implementor that already mandates SSL.</p>
  
  <p>What am I missing here? Internet Inertia?</p>