Any authentication situation where there is a distributed secret is fundamentally broken. Unless every app developer runs their own proxy that holds the secret key, and then validates incoming requests from their users before forwarding them on to Twitter, OAuth can't be expected to validate that a particular client was used to send a request. End-users of the app could be validated by their product key or similar (individual secrets). Obviously running a proxy is not practical for every app maker but it's already being used for a lot of situations (e.g. IM clients with push on the iPhone).
I don't think there is any protocol besides PKI with client-side certs that can guarantee authenticity of the client from the API's perspective. The app developer registers a secret key with Twitter, and uses it to sign individual certificates for each user that buys their app. Twitter can then verify from the certificate that it is receiving a request from user X using client Y made by the app developer.
No. Any authentication situation where every end user needs to protect a secret shared among many end users is fundamentally broken. That's not the same as what you just said.
OAuth works well for web apps. OAuth works less well for native apps. It's not "fundamentally broken"; it's just been stretched past its design limits in iPhone/Android settings.
The other side of this is that OAuth does backflips to work within the limitations of browsers and web applications. Native clients have much better options than OAuth for strong authentication. As a result, there's much less need for a standardized shared authentication protocol for native apps; OAuth actually doesn't make life much simpler for end-users or app developers than most "interesting" web services auth protocols already are.
This problem absolutely does not require a PKI to solve.
> No. Any authentication situation where every end user needs to protect a secret shared among many end users is fundamentally broken. That's not the same as what you just said.
OK, I was imprecise in my language. You clarified what I meant.
> This problem absolutely does not require a PKI to solve.
How would you solve it for native apps? By "it" I mean enabling the API to be sure that user X submitted the request with app developer Y's real client. Without having the app developer sign something for every user downloading the client, or running a proxy.
I don't think there is any protocol besides PKI with client-side certs that can guarantee authenticity of the client from the API's perspective. The app developer registers a secret key with Twitter, and uses it to sign individual certificates for each user that buys their app. Twitter can then verify from the certificate that it is receiving a request from user X using client Y made by the app developer.