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.