Mark, Thanks for weighing in. Much appreciated. Here are my thoughts.
I see two separate issues here: User Authentication vs. Application Authentication. User Authentication: Ensuring that the Twitter user is who they say they are. Application Authentication: Ensuring that the Application is who it says it is (i.e. the tweet is really coming from "TweetDeck" and not some other application pretending to be TweetDeck). User Authentication: I understand that Basic Auth, as is, is not a secure solution. Transmitting unencrypted credentials in the clear is never a great idea. What about combining Basic Auth with a form of public/private key encryption? Using PGP as an example, Twitter could publish it's public PGP key. Applications using Basic Auth would have to encrypt the username and password with that key and submit the encrypted username and password as the Basic Auth credentials. Twitter decrypts them server side and processes authentication normally. Developers wouldn't have to include any sensitive information in their source code, and the credentials would always be transmitted in an encrypted fashion. PGP is a fairly robust standard, with lots of free resources available to the development community across many languages. Application Authentication: This is a thornier issue that I'm not sure how to solve without having to bundle some sort of sensitive information in the source code of an application. However, I think the issue becomes more manageable if User Authentication is separated from Application Authentication. I have no doubt that many of the folks on this list have good ideas on how to solve the second problem. Thoughts Regards, Duane On Jul 1, 12:46 pm, Matt Sanford <m...@twitter.com> wrote: > Please, take your time and write a well thought out reply. One- > line snarky comments, while fun to write and sometimes to read, steal > time from everyone reading the list, including all of the Twitter API > engineers. They also make the list look less inviting to new comers.
