so excited about xAuth. i think this is really going to change the landscape in a big way. can't wait to get going. sent a message to a...@twitter.com -- that's all that's necessary to get going right?
thanks again, isaiah On Feb 12, 2010, at 9:04 AM, tsmango wrote: > Yep, I meant mobile native applications. This is really a wonderful > idea! Very, very happy about this! > > On Feb 12, 11:15 am, Raffi Krikorian <ra...@twitter.com> wrote: >> if, of course, you mean a mobile native application, and not a mobile web >> application. mobile web applications still need to send their users through >> the regular oauth workflow. >> >> >> >> >> >> On Fri, Feb 12, 2010 at 8:15 AM, Raffi Krikorian <ra...@twitter.com> wrote: >>> yup! that's the plan. sorry if it wasn't clear in the e-mail blast. >> >>> On Fri, Feb 12, 2010 at 6:14 AM, tsmango <tsma...@gmail.com> wrote: >> >>>> Just to clarify, xauth will be available to mobile applications (who >>>> apply) going forward to authenticate users, not just a one time way to >>>> exchange stored usernames and passwords? >> >>>> On Feb 11, 10:18 pm, Raffi Krikorian <ra...@twitter.com> wrote: >>>>> hi all. >> >>>>> this is a long overdue e-mail, but i wanted to tease out some of the >>>>> directions that Twitter is going with OAuth. i want to touch upon four >>>>> topics: delegation, OAuth WRAP/2.0, username/password OAuth token >>>> exchange, >>>>> and basic authentication deprecation. >> >>>>> *DELEGATION - OAuth Echo* >> >>>>> twitter users love posting media on third-party sites, and delegation in >>>>> identity verification is one of the major hurdles for an OAuth-enabled >>>>> twitter client to succeed. i started a series of blog posts around the >>>>> following problem: >> >>>>> You're an OAuth enabled Twitter client, and you've already authorized >>>> your >> >>>>>> user. Your user wants to use a media providing service like TwitPic. >>>>>> TwitPic, currently, asks for the username and password of your user >>>> so it >>>>>> can store the photo on behalf of the Twitter user. You don't have >>>> that >>>>>> username and password, so how do you give the ability to TwitPic to >>>> verify >>>>>> the identity of your user? >> >>>>> check out the proposal for what we're calling "OAuth Echo" athttp:// >>>> mehack.com/OAuth-echo-delegation-in-identity-verificatio. please >>>>> feel free to comment there, or on the twitter development talk mailing >>>>> list<http://groups.google.com/group/twitter-development-talk>(or, even >>>>> just reach out to me directly). i think this experiment in >>>>> engaging the community around designing this security/identity workflow >>>> has >>>>> been definitely a success, and i feel we're rapidly converging on a >>>> solution >>>>> for identity verification delegation. in parallel, we're going to start >>>> the >>>>> process to engage our media providers in the conversation as well, and >>>> we're >>>>> hopeful we can move this forward quickly. >> >>>>> *OAUTH WRAP/2.0* >> >>>>> OAuth is evolving, and we at Twitter are keeping up with it. that being >>>>> said, we're keeping our eyes on OAuth WRAP and OAuth >>>>> 2.0<http://wiki.oauth.net/OAuth-WRAP>. >>>>> we like a lot about it: >> >>>>> - it requires the use of SSL; >>>>> - there is no custom signing mechanism -- you simply pass us a token, >>>> and >>>>> that token is secured by SSL; and >>>>> - it formalizes a bunch of "profiles" that we've been actively >>>> thinking >>>>> about (e.g. a username/password exchange) >> >>>>> in general, we really like WRAP/2.0 because it's just *so* easy to >>>> implement >>>>> from the client side. there are no longer questions around creating the >>>>> proper signature base string, etc. we're sure that developers will like >>>> it >>>>> as well. we've started work on an internal implementation of OAuth WRAP >>>> and >>>>> we envision that we'll simultaneously support both OAuth 1.0a and >>>> WRAP/2.0 >>>>> for a while. our hope is to get WRAP out the door soon (and before we >>>>> finally deprecate basic authentication). >> >>>>> *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth* >> >>>>> @rsarver and @noradio announced that we are going to support a mechanism >>>>> where a username and a password can be directly exchanged for an OAuth >>>> token >>>>> and secret -- we're calling this xAuth. if you've been watching the >>>> mailing >>>>> list, Seesmic Look <http://seesmic.com/look> has been a beta partner in >>>>> testing xAuth exchange (and @abraham has already detailed how it >>>>> works< >>>> http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser.. >>>> .>). >> >>>>> because we're moving everybody off basic authentication, we originally >>>>> envisioned this as a mechanism for developers to exchange all the >>>> username >>>>> and passwords they have in their databases for OAuth tokens en masse. >>>>> that's still one of our use cases. another use case is around >>>> environments >>>>> where software can't bring up a web browser (e.g. set top boxes, game >>>>> consoles, embedded devices). we want to support those as well. >> >>>>> you're going to have to apply to get access to this exchange mechanism >>>> (by >>>>> sending e-mail to a...@twitter.com), but, in general, all applications >>>> except >>>>> web applications will get access. we feel that the xAuth exchange >>>> allows >>>>> for the best mix of security and user experience for desktop and >>>> possibly >>>>> mobile applications. web applications will simply have to use OAuth as >>>> it >>>>> was designed, and send their users through the web flow. >> >>>>> *BASIC AUTHENTICATION DEPRECATION* >> >>>>> yup - it's still happening. we're targeting June 2010. everybody, >>>>> including legacy applications, will have to move over. >> >>>>> for those who are building new applications, use OAuth. save yourself >>>> the >>>>> transition time later, and start thinking about it now. for those who >>>> have >>>>> applications already out there, it would be really beneficial to start >>>>> thinking about a migration path right now and we're here to help. if >>>> you >>>>> need it, please feel free to reach out to us and we'll help you figure >>>> out >>>>> what you need to do. >> >>>>> to help entice you over, as you know: >> >>>>> - we have increased rate limits on api.twitter.com to those who are >>>> using >>>>> OAuth (350 calls to the REST API per hour -- and increasing towards >>>>> 1500/hour); and >>>>> - (as some of you are painfully aware) you can only set a source >>>>> parameter with OAuth calls to status/update. >> >>>>> we know some of you think there are hurdles in places to converting over >>>> to >>>>> OAuth -- suffice it to say, we're actively trying to address them. some >>>>> potential hurdles are mentioned in this e-mail, and if you think there >>>> are >>>>> more then please feel free to reach out to us. again, we really want to >>>>> make this switch-over easy for everybody. >> >>>>> thanks! and, as always - feel free to reach out to us anytime here, or >>>> to >>>>> @twitterapi. >> >>>>> -- >>>>> Raffi Krikorian >>>>> Twitter Platform Teamhttp://twitter.com/raffi >> >>> -- >>> Raffi Krikorian >>> Twitter Platform Team >>> http://twitter.com/raffi >> >> -- >> Raffi Krikorian >> Twitter Platform Teamhttp://twitter.com/raffi
