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 Team http://twitter.com/raffi
