> > Great to hear it’s on your radar and you’re actively working on it. Any > chance you’ll involve the dev community prior to presenting the solution as > a fait-accompli? And do you have an idea around timing for this solution? >
yes, and no. :P > > > On 12/10/09 9:55 AM, "Raffi Krikorian" <[email protected]> wrote: > > we're not unwilling to answer the question. it is something we're actively > working on, and we're just not in a state to release anything yet. > > On Thu, Dec 10, 2009 at 9:52 AM, Michael Steuer <[email protected]> wrote: > > Raffi - can someone at Twitter PLEASE comment on the delegation question? > If > your app uses the web oauth flow, as strongly recommended by Twitter and > reiterated in your statement below, how do you see consumption of 3rd party > APIs happening when you don't have the user's un/pw? I don't understand why > you're so unwilling to address that question? > > > On 12/10/09 7:42 AM, "Raffi Krikorian" <[email protected]> wrote: > > > don't be evil. in a web scenario, send them to twitter.com < > http://twitter.com> for the > > > oauth workflow. in the case that you can't do that, do not store the > > username and password - simply pass them through and store the tokens > > instead. > > > >> @ michael > >> " The web case is different - a web site doesn't have the user's > credentials > >> unless they explicitly provide them." > >> With the new oAuth implementation even web apps will be allowed to > collect > >> user's credentials. There is no way to enforce webapps to delegate > >> authentication > >> > >> > >> On Thu, Dec 10, 2009 at 8:42 PM, Michael Ekstrand <[email protected]> > >> wrote: > >>> > >>> John Meyer wrote: > >>>> okay, forgive me if I'm wrong, but wasn't the whole point of oAuth > >>>> that the application didn't need to know the username/password? That > >>>> the user would grant access to the application and then the > >>>> application would store that rather than the actual > >>>> username/password. Or am I missing the point of going to an oAuth > >>>> system? > >>> Yes, that's the point of OAuth. However, the dynamics of a web-based > >>> application vs. a desktop application complicate things. If the user > is > >>> trusting an application to run natively on their desktop, that > >>> application already has access to their username and password (it can > >>> read them from config files, do a keyboard grab when it spawns the > >>> browser, go snooping around in Firefox's memory space, any number of > >>> things). Thus, in the desktop application case, allowing the user to > >>> input their username and password does not decrease security except > >>> perhaps by not always enforcing "don't give away your password". The > >>> web case is different - a web site doesn't have the user's credentials > >>> unless they explicitly provide them. > >>> > >>> I'm ignoring for the present sandboxed or sandboxable environments such > >>> as Java and AIR. The runtime may prevent the local application from > >>> having access to the username/password as used by other applications. > >>> > >>> - Michael > >>> > >>> -- > >>> mouse, n: A device for pointing at the xterm in which you want to type. > >>> Confused by the strange files? I cryptographically sign my messages. > >>> For more information see <http://www.elehack.net/resources/gpg>. > >>> > >>> > >> > >> > > > > > > > > > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
