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

Reply via email to