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?
On 12/10/09 9:55 AM, "Raffi Krikorian" <ra...@twitter.com> 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 <mste...@gmail.com> 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" <ra...@twitter.com> 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 <mich...@elehack.net> >>>> >> 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>. >>>>> >>> >>>>> >>> >>>> >> >>>> >> >>> > >>> > >> >> > >
