Re: [twitter-dev] Re: What's up with OAuth?
we're in the process of putting the last pieces of infrastructure in place -- once that is in place, then the turnaround time on requests will be fairly quick. right now, all requests are being logged, and will be responded to. On Wed, Feb 17, 2010 at 7:23 AM, Shannon Whitley swhit...@whitleymedia.comwrote: Hi, What is the expected wait time after submitting a request for xAuth access? I'm trying to let a client know how long the development cycle will take, but a lot depends on this approval. My request is currently pending from Thursday or Friday of last week. Thank you. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: What's up with OAuth?
If I am not mistaken, the oauth_verifier is for the PIN. So if you are not a desktop app, then its not required. Ryan Sent from my DROID On Feb 14, 2010 1:04 AM, jon jonhoff...@gmail.com wrote: It worked for a one time oauth conversion for about 3000 accounts (i ran a batch job across five processes and think it took an hour or so to finish)-- however, that was back in may. the script was also written pre oauth 1.0a, so there's no oauth_verifier. I'm not sure if that's required now. On Feb 13, 11:41 am, Dewald Pretorius dpr...@gmail.com wrote: Mmmm it looks as if you're sc...
Re: [twitter-dev] Re: What's up with OAuth?
Now, I've had a quick look at how Seesmic Look does the authentication process and I've got two questions: 1.) Will it be possible to run the xAuth authentication over a HTTP proxy? It looks like it's possible at first glance. I've got a lot of users from countries where Twitter is blocked and it would be crucial for them to run through an API proxy. i don't see why not, as long as the proxy can handle HTTPS connections... 2.) Is SSL absolutely mandatory for retrieving the access token? The reason for this question is that I've got quite a number of users which cannot use SSL (due to misconfigured network operator HTTP proxies.) Gravity is using SSL by default, but once it detects a problem with using SSL, it will fallback to plain HTTP. unfortunately, as i see it now, xAuth will require SSL. Cheers thanks for coming up with xAuth! :-) Ole np :P -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: What's up with OAuth?
similar idea, different implementation. when we deploy WRAP/2.0, the corresponding profile would be the username/password profile. On Fri, Feb 12, 2010 at 3:42 AM, yegle cnye...@gmail.com wrote: Hi Raffi, Is xauth the same as the 5.3 Username and Password Profile in WRAP's specification? On Feb 12, 11:18 am, 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 listhttp://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.0http://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
Re: [twitter-dev] Re: What's up with OAuth?
yup - we're actively working on a fix for the mobile oauth pages (as well as a complete redesign of the oauth pages in general). On Fri, Feb 12, 2010 at 3:47 AM, Terence Eden terence.e...@gmail.comwrote: Will mobile OAuth be fixed for all users before this goes live? See http://code.google.com/p/twitter-api/issues/detail?id=395 for details. On Feb 12, 3:18 am, 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. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: What's up with OAuth?
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 listhttp://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.0http://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
Re: [twitter-dev] Re: What's up with OAuth?
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 listhttp://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.0http://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
Re: [twitter-dev] Re: What's up with OAuth?
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 a...@twitter.com -- that's all that's necessary to get going right? thanks again, isaiah 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 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 listhttp://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.0http://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
Re: [twitter-dev] Re: What's up with OAuth?
yup - they do :) On Thu, Feb 11, 2010 at 8:12 PM, kehers keh...@gmail.com wrote: Talking xAuth, hope mobile apps count as 'applications except web applications' -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: What's up with OAuth?
Talking xAuth, hope mobile apps count as 'applications except web applications' yup - they do :) Already signed up (I think) for u/p - OAuth Token. WRAPped, even better. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- New political correctness is but old fascism writ large. -- Dr Digby James -
Re: [twitter-dev] Re: What's up with OAuth?
He specifically states the possibility for mobile apps to use xAuth. Ryan Sent from my DROID On Feb 11, 2010 11:27 PM, kehers keh...@gmail.com wrote: Talking xAuth, hope mobile apps count as 'applications except web applications'
