Interesting idea.
On Jun 11, 6:56 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > Hi Developers, > > As has been discussed on the list recently, OAuth and Open Source > applications are a difficult combination because token secrets shouldn't be > embedded in widely distributed code. > > We're pleased to announce that we've devised a solution to this problem. > > Next week, we plan to release a new extension to the Twitter API that will > allow Open Source applications to obtain OAuth consumer keys and secrets for > their users, without having to distribute an application secret. > > Approved Open Source client applications will have an easy to implement > ability, through dev.twitter.com, to generate new client tokens & secrets to > be used specifically for each new instance of the application. > > While completing the process does require the end-user to complete a few > extra operations, we think this is a good compromise. > > The source tag on tweets published by the child applications generated with > this approach will be a variation on the originating application's name. For > examples, if the name of the parent application was "AdventureTweet" and the > user's screen name was @zork, then the child application's name would be > "AdventureTweet (zork)". > > The work flow for these applications will be something like this: > > 1. You store your API Consumer Key in your application distribution (but > never your secret!). > 2. A user downloads/installs/checks out your open source application and > runs it for the first time > 3. Your application builds a URL to our key exchange endpoint, using your > consumer key. > > Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi... > 4. You send the user to that URL in whatever way makes sense in your > environment. > 5. That user will have to login using their Twitter credentials (if they > aren't already), and then approve your application's request to replicate > itself on the user's behalf. > 6. The approval will require that the user agrees to our terms of service, > as this process results in them having control of their own application > 7. The user is presented with a string that they are asked to paste into > your application. The string will contain ah API key and secret, in addition > to an access token and token secret for the member: everything that's needed > to get the user up and running in your application. > 8. The user pastes the string into your application, which then consumes > and stores it to begin performing API calls using OAuth. > > The string containing the keys will be x-www-form-urlencoded. To keep the > string brief, it will contain abbreviated key names. > > An example: > ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=542212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55dKx7AAaI8NfpK7xnibv4Yls > > Where: "ck" - consumer key, "cs" - consumer secret, "at" - access token, > "ats" - access token secret > > This kind of key requisition service is new to the Twitter ecosystem, and > we're going to be closely monitoring it for abuse. Once we announce its > availability, we'll begin taking requests for Open Source applications that > would like to offer the feature in their application. > > We're excited to offer this solution to the open source community. Thanks > everyone! > > Taylor Singletary > Developer Advocate, Twitterhttp://twitter.com/episod
