Yeah basically twitter can allow developers to generate children keys from their master key they received during application registration. The developer is then free to delegate the generated "children" to whom ever they wish. This gives us freedom to then pick who can sign requests using our application name. We can be very open with this (basically a hidden, public API for the desktop applications) or restrictive (password/secret guarded API) on our end.
Josh On Sun, Jan 31, 2010 at 10:45 AM, Raffi Krikorian <ra...@twitter.com> wrote: > this is an interesting idea -- what twitter could do is keep "key > hierarchies" mapping a master consumer key to subsidiary consumer keys...? > > On Sun, Jan 31, 2010 at 8:04 AM, 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 > > > > -- > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi >
