Dave Winer, 56, is a visiting scholar at NYU's Arthur L. Carter Journalism Institute and editor of the Scripting News weblog. He pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software; former contributing editor at Wired Magazine, research fellow at Harvard Law School, entrepreneur, and investor in web media companies. A native New Yorker, he received a Master's in Computer Science from the University of Wisconsin, a Bachelor's in Mathematics from Tulane University and currently lives in New York City.
"The protoblogger." - NY Times.
"The father of modern-day content distribution." - PC World.
"Dave was in a hurry. He had big ideas." -- Harvard.
"Dave Winer is one of the most important figures in the evolution of online media." -- Nieman Journalism Lab.
10 inventors of Internet technologies you may not have heard of. -- Royal Pingdom.
One of BusinessWeek's 25 Most Influential People on the Web.
"Helped popularize blogging, podcasting and RSS." - Time.
"The father of blogging and RSS." - BBC.
"RSS was born in 1997 out of the confluence of Dave Winer's 'Really Simple Syndication' technology, used to push out blog updates, and Netscape's 'Rich Site Summary', which allowed users to create custom Netscape home pages with regularly updated data flows." - Tim O'Reilly.
8/2/11: Who I Am.
My 40 most-recent links, ranked by number of clicks.
FYI: You're soaking in it. :-)
I know OAuth pretty well since I implemented a client a little over a year ago. It was hard work, but I got there, with help from one of the designers, Joseph Smarr. This version of OAuth, 1.0, worked something like Flickr's authentication system, which I had implemented a few years earlier. Wasn't sure what was gained with the new complexity, but Twitter had said pretty clearly they were moving to OAuth, and I was actively developing on Twitter, so I figured I'd better support it.
Since then there's a new OAuth that is incompatible with the one I implemented. I'm confused now about which one Twitter will use, but I don't care because in the interim I stopped developing Twitter apps. I've decided that when and if Twitter pulls the plug on non-OAuth apps, I'll just let my apps break.
The other day I had to write some OAuth code for another web app, and it was a bitch -- my Twitter-OAuth code didn't work with the new app. So we're in the place you don't want to be, with compatibility expressed in terms of apps instead of standards. It should be enough to support OAuth, but it's not.
The new OAuth is an attempt to simplify it, and if that's what we're doing, why not go all the way and make it Really Simple™ (sorry). Hey it's an open format, so anyone is allowed to have an opinion. So here goes.
Imho FriendFeed had a good idea. Instead of giving an app your password, you give it your remote key -- a random string they generate for you. So now you've authorized apps to access your account without giving them your password. No protocol change, we're still using Basic Authentication. The user's life gets a little more difficult, but so little it's hardly worth mentioning. They just have to understand this idea of a remote key. And it stays truly simple for developers.
But that's not as good as OAuth because it doesn't allow the user to selectively turn off one app while leaving the other apps alone. (Note that you always had the power to turn off all the apps, just change your password, and boom none of them can get into your account.)
Credit card companies have had a solution to this for a long time. Consumerist has an excellent survey of the field. Each bank calls them something different, but they're all the same idea. CitiBank calls them virtual account numbers. They're credit cards that are good only at a single merchant. If you don't like what that merchant is doing you can just terminate the virtual account and they stop misbehaving right away, leaving all your other online accounts alone. All the virtual accounts funnel into the same account you've always used, but you can do business without giving away that account number. Now when someone steals your identity, they've got nothing. Isn't this exactly what we want from authentication? And it can be implemented without creating any new hurdles for developers.
Credit card companies use these numbers to protect their money, so why isn't it good enough for us to protect our users' identity?