FYI, if anyone wants to get an to do a poor man's version of xAuth,
I'd written a script a few months ago to exchange credentials:
On Feb 12, 8:52 pm, Norio Nomura <norio.nom...@gmail.com> wrote:
> I tested xAuth with below
> and succeeded.
> I want to know about xAuth's current status and roadmap.
> Norio Nomura
> On 2月12日, 午後12:18, 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