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 -- that's all that's necessary to get going 

thanks again,

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 <> 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 <> 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 <> 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 <> 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://
>>>>  please
>>>>> feel free to comment there, or on the twitter development talk mailing
>>>>> list<>(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<>.
>>>>> 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).
>>>>> @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 <> has been a beta partner in
>>>>> testing xAuth exchange (and @abraham has already detailed how it
>>>>> works<
>>>> .>).
>>>>> 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, 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.
>>>>> 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 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
>>> --
>>> Raffi Krikorian
>>> Twitter Platform Team
>> --
>> Raffi Krikorian
>> Twitter Platform Team

Reply via email to