Just to add more . There will always be only one level of sub keys in the hierarchy. Everytime the user downloads the same app the same key pair will be given (like access token/secrets) (a user authentication may be made mandatory in this case)
On Mon, Feb 1, 2010 at 12:39 AM, srikanth reddy <srikanth.yara...@gmail.com>wrote: > 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 >> > >
