Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy.
Just wondering if twitter could actually replace 'PIN' part with those key/secret pair i.e when the user clicks 'Download app' link in apps webpage it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required) twitter will generate the new key/secret pair and it will either 1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or 2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded. Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either. If UX is an issue then the first approach may be used. Any comments on this? On Sun, Jan 31, 2010 at 9:34 PM, Josh Roesslein <jroessl...@gmail.com>wrote: > I wonder if Twitter could provide developers with an URL for > dynamically generating additional consumer tokens for their > applications. When the user installs a new application it will contact > the developer's server to download its own consumer key/secret. The > developer's server will use its "master" consumer key/secret to post > to the Twitter URL to fetch a new consumer key/secret. The consumer > pair will then be sent to the application via a secure channel > (HTTPS?) to prevent man in the middle attacks. The application will > then use this new consumer pair to perform all signing of requests. > Another option is to package the dynamically generated consumer pair > in the application download package. Each new download will have its > own unique consumer pair ready for use once the user has downloaded > the application. > > This still requires the developer maintain a server to perform the > consumer pair generation, but it does keep the "master" pair secure > and each application gets its own pair. But applications that are > willing to make this trade off can keep the UX good, control what > application instances can authorize on the application's behalf, and > the "master" pair is never shared. You can always still distribute the > "master" pair with each application if these security gains are not > that important to you. Or you can require your users to generate their > own consumer pair if UX is not much of an issue (example: distributed > server applications) where an advance users is at the wheel and won't > have issues figuring this out. > > Josh >
