Disclosure and disclaimer: I am a software engineer at Microsoft, but the following post (just like all other posts on this blog) is my own and in no way represents the views of Microsoft. All statements regarding Microsoft expressed here are my opinions based on publicly available information.
When I started working on DotNetOpenAuth (by its former name of DotNetOpenId) in 2007 my primary motivation was to act as a kind of “Internet consumer privacy advocate.” End users on the Internet are pawns in an ocean of big companies that want to collect as much of your personal information as they can. Their privacy policies may change more frequently than women’s fashion, but much more subtly as most users don’t read them and couldn’t understand their ramifications even if they did read them. It is apparent to me that no for-profit business is going to truly be on the customer’s side to protect their interests really. Sure, they’ll claim to champion privacy while using that assurance to woo away the private information from their customers and store on servers to be analyzed later either by themselves or by government subpoenas. I endeavored to truly represent the end user’s interests as I participated in identity-centric mailing lists, attended OpenID conferences, etc.
Passwords are horribly implemented and overall just a bad idea compared with modern alternatives. Back when I began working on DotNetOpenId, “Microsoft Passport” was just failing as an attempt to make it easier for users and sites to authenticate, but at the ridiculous cost of $10,000 per relying party just to sign up, and then you have the central controlling entity problem. OpenID promised a decentralized way to solve the problem that really appealed to me. It still does.
Information Cards (a.k.a. Windows CardSpace) was another Microsoft attempt to solve the authentication problem. Two flavors existed: m-cards and p-cards as they were known. Managed cards relied on a business having issued them, while personal cards were self-issued. I really believed in p-cards because they truly gave users control of their own identity and actually presented it in a user-friendly way. Unlike (most) X.509 certificates or m-cards, p-cards were self-issued and self-asserting, so that only your local computer could authenticate you. Weaknesses in implementation that gave CardSpace bad startup perf, and abysmal marketing of the technology were the two factors which (IMO) led to its ultimate demise and removal from later versions of Windows.
I had preferred Information Cards over OpenID because of users having ultimate control instead of some server (usually a big company) that actually owned the identity of the customer. But I really appreciated and helped drive OpenID adoption with DotNetOpenAuth because as p-cards were not being adopted, I saw OpenID as the greatest practical hope end users had. And while OpenID isn’t perfect, getting everyone to adopt it would not only educate web developers and users that there is a better way, if successful, it would force the re-thinking of user identity so that a superior successor to OpenID could eventually come in to replace it with much less friction than the earlier password-to-OpenID transition.
DotNetOpenAuth has been my contribution to help in this effort, because I didn’t see Microsoft, or anyone else, helping the .NET community to write better authentication in ASP.NET applications. I saw a gap and wanted to fill it. OAuth 1 and OAuth 2 came along and as it helped put the user a bit more in control of their data (by removing the need for users to disclose their passwords with arbitrary 3rd parties) it made sense to add support for authorization protocols into DotNetOpenAuth.
It’s been several years, and times change. Google, Yahoo, AOL, and Microsoft have all taken identity and web authentication for ordinary end users more seriously. They still grab increasing amounts of customer data, but authentication to their services and to 3rd party web sites that access data with these big companies has really improved over the years. The gap between what was offered and what end users deserved, that originally attracted me to this space, has largely been closed. Most particularly for me, the ASP.NET team has released libraries that build on and beside DotNetOpenAuth to make it even easer to build web sites that offer secure authentication options. With corporations now paying engineers to do what I was doing without pay, I’m happy to refocus my efforts elsewhere.
So as the title of this post suggests, my limited time for spending on projects like these requires that I move my focus away from DotNetOpenAuth. I plan to step down as leader of the DotNetOpenAuth project by June 30, 2013. I hope by then someone I can endorse will step up to take the baton and keep supporting the large user base we currently have. DotNetOpenAuth has probably amassed more than 1 million downloads in total over its lifetime, which isn’t huge for popular open source projects but does make it in one of the top tiers, I think. It’s user base is loyal and I do not want to leave them stranded. I appreciate all the support they’ve shown. I will continue to provide some minimal maintenance support for as long as necessary (and my resources allow) for security patches, etc. If you’ve been at least semi-active in the DotNetOpenAuth community and are interested in filling in as (one of) the project lead(s), please email me. You’ll know how to reach me. 🙂 We may even set up some kind of community voting if we get several good volunteers, as this certainly isn’t something I need to control.
This decision has not been an easy one. In fact I’ve struggled to make it for the last year or so. With the news coming in the last couple years of massive user data leaks (whether intentional or otherwise), I’ve finally been pushed over the edge to change my focus.
I should call out a big thanks to David Christiansen, who has collaborated with me on DotNetOpenAuth for years, and found us free web hosting, created or helped with several of our web sites, etc. He has volunteered to help with the transition to a new project lead.
There is a major release of DotNetOpenAuth that has been in the making for several months. DotNetOpenAuth 5.0 is a huge update to use the latest that the .NET 4.5 platform has to offer. I hope to either wrap up that release and publish it before I step down, or have it close enough that some successor(s) to the project can complete the work and release it soon.
My passion for Internet consumer privacy has led me to a new gap – one that I think corporations will be much slower to try to fill and thus makes it more important for independent folks like myself to work to fill it. I now work (when I’m not working at my day job) to protect the authenticity and confidentiality of Internet communications and private data. With the advent of moving everything into the cloud from files (SkyDrive, Google Drive, DropBox) to communications (Gmail, Hotmail, Skype, Facebook, Google+), customer data may have never been more at the whim of big company policies – or technical foul-ups. These things can be and are monitored both by the companies and by governments. And I don’t care how much you trust your current government, there’s no telling how well you’ll trust government when an opposing party is in control (assuming you live in a democracy or a republic such as the U.S.). I’ll stop there and save more feelings on this topic for another post.
My next focus then is to provide an authenticated and confidential alternative to email. The SMTP protocol for emails is one of the oldest protocols on the Internet, and also one of the least secure. Users deserve the privacy they ignorantly assume they have when sending emails to others. Yes, there are already many technologies and services out there that claim to provide confidentiality and authenticity assurances for email (PGP is noteworthy because it’s actually a decentralized solution rather than depending upon and trusting a company). But as far as I have found, they all fall short.
IronPigeon is my new project. It is a general message passing protocol upon which email-like experiences can be built that provides ultimate confidentiality and authenticity assurances. And it is very carefully designed to be totally decentralized. No one need rely on or trust a server in the cloud, and no malfunction or loss of a central service will cripple the network. The protocol has the ability to route messages between users without knowing who is sending or receiving the message, how large the message is, or what any of its content is (headers included). Perhaps I could patent and sell such a protocol, but as my motivation is to help end users, my goal is to maximize adoption and thus I make it available for free. If there is sufficient interest, maybe we’ll kick up a WG to standardize the protocol.
Of course a protocol by itself is of no use to end users. We need user-friendly apps written that support the protocol available on all platforms and devices. I’m working on a couple of these apps myself but have limited time, resources, and UX talent to do a thorough job everywhere. So I am really hoping the community picks up on this to write apps based on it.
To those of you who are only interested in my work because of authentication-related topics, thank you for your following, and I wish you the best. For those whose interests span into the more general topics of user privacy, I hope to see much more of you (and from you) as we embark to create an open and individual user-controlled ecosystem for our world community.
Andrew, I cannot tell you how much I respect the work you have done and the support you have provided to the user community for DotNetOpenAuth. I do hope development continues and potentially thorough documentation is written ( I think you would do well if your wrote a book).
You are spot on with your assessment that communication protocols need to be shored up in a major way. I cannot think of a project that would promote internet freedom more directly.
It is a massive challenge. I thought Google Wave was going to be the communication protocol of the future and unfortunately, it died. It would be hard to say why but I don't think Google got out into the community either from a developer or CIO perspective to promote it enough. There was a long period of time where it did not interoperate with existing protocols, and I think that is a big part of getting a new protocol to slip into the mainstream. I think the economy also got to a point where Google needed to focus on what benefited Google and not general use software.
I hope with your project you are able to engage consumers, programmers, network administrators and corporate officers equally because migrating off of SMTP takes everyone getting involved. It's going to take a LONG time, much like the transition to IPV6. I hope you have the stamina.
Thanks, Richard. As my target audience is the typical end user, I don't expect to be evangelizing to network admins or corporate officers. The protocol works through firewalls already since it's just HTTP(s). We can use as many programmers across platforms as we can get, however.
As far as corporate interest, I suspect some corporations will actually dislike IronPigeon because it prevents them from filtering and monitoring their employees' email. So it's really on the non-goal list to reach out to them.
If I am now building a new website, do you suggest I use something other than DotNetOpenAuth for OpenId logins?
@Baruch, not at this point. DotNetOpenAuth is still by far the best (and AFAIK only) library for OpenID logins.
I am having sooo much trouble trying to get it to work. Where can I get answers to my questions?
@Baruch,
You can try stackoverflow or the dotnetopenid@googlegroups.com mailing list.
The OpenID relying party flow is actually fairly simple. You can find samples by downloading the samples file on http://sourceforge.net/projects/dnoa/
Can you comment on how this differs from the work at TorProject.org?
@Richard, TorProject.org is about browsing the web anonymously. My efforts on IronPigeon focuses on securing email — not to make it anonymous, but to make it private as it should be.
Hi Andrew
First of all I must say amazing work and kudos to your thought process and intent !
The dotnetopenauth library looks promising on paper, but I was a bit taken aback by the fact that there are no workable samples, documentation or APIs usage examples for the SMTP protocol in general (Gmail in specific).
Please point me in the right direction if my statement is wrong.
@TrueLies: DotNetOpenAuth doesn't offer anything for the SMTP protocol. So that would explain why you can't find anything about it. What made you think there was SMTP support?