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" at
http://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-browserless.html>).


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

Reply via email to