OAuth 2.0 and the Road to Hell. They say the road to hell is paved with good intentions. Well, that’s OAuth 2.0. Last month I reached the painful conclusion that I can no longer be associated with the OAuth 2.0 standard. I resigned my role as lead author and editor, withdraw my name from the specification, and left the working group. Removing my name from a document I have painstakingly labored over for three years and over two dozen drafts was not easy. Deciding to move on from an effort I have led for over five years was agonizing. There wasn’t a single problem or incident I can point to in order to explain such an extreme move. All the hard fought compromises on the mailing list, in meetings, in special design committees, and in back channels resulted in a specification that fails to deliver its two main goals – security and interoperability.
When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure. How did we get here? Labs/Weave/Identity/Account Manager. The Account Manager project aims to produce: A protocol definition that sites can use to define their account-and-session management features in a format a web browser can understand. (The latest draft of the specification is here). An implementation of this protocol as a Firefox addon.
The goal is to help users manage the process of "connecting" to a site, in a way that allows us to use secure browser chrome, and supports multiple authentication mechanisms. The account manager is an evolution of the Firefox password manager and the Weave identity components (OpenID + auto-login). Creating a new identity framework is a non-goal of this project, although some new file formats and protocols are in scope (see below for details). There is additional information in the announcement blog post, as well as the add-on's first-run page.
Mike Hanson Dan Mills Aza Raskin (UX/Labs) Alex Faaborg (UX/Firefox) Specification Addon Latest release Simple Connect Two Users, One Firefox Mass Password Reset Backend. OAuth — An open protocol to allow secure API authorization in a. Home - Liberty Alliance. MOVIM - Plateforme Sociale Libre.
CardSpace ou la gestion des identités et accès. CardSpace ou la gestion des identités et accès Par Keith Brown et Mis à jour par Pierre Couzy Êtes-vous las de la gestion et de la sécurisation d'un ensemble toujours plus important de noms d'utilisateur et de mots de passe ? Êtes-vous las de remplir sans cesse des profils utilisateur pour des sites Web qui souhaitent glaner des informations personnelles vous concernant ?
Aimeriez-vous faciliter la tâche des utilisateurs qui souhaitent se connecter à vos sites et services Web ? Êtes-vous préoccupé par le vol d'identité et le phishing ? Si tel est le cas, lisez ce qui suit. Je vais présenter une nouvelle couche d'identité pour Internet, qui sera exposée aux utilisateurs via une interface utilisateur dont le nom est « CardSpace » (ex-InfoCard). Sur cette page Un métasystème d'identité Les sept lois sur l'identité Identité numérique et affirmationst Le sélecteur d'identité Que contient une carte ? De combien de cartes ai-je besoin Cartes émises personnellement Comment obtenir CardSpace ? Haut de page. OpenID Foundation website.
OpenID Connect | FactoryCity. I’ve been thinking about how we make OpenID both easier and sexier for quite a while now. As frustrating as the answer may be to technologists, the problem is not necessarily one that can be solved with more technology. Instead, at some point, you have to move beyond the original constituents of a solution and start to package up the thing in a way that is less alienating, and less “insider baseball”. “OpenID Connect”, therefore, is what I’m starting to use in casual conversation as my answer to Twitter and Facebook Connect. It’s really creative, I know. That’s why they pay me the big bucks. Seriously though, from a marketing perspective — it’s what I want the OpenID Foundation (and our new board ) to offer the world in 2010. At some point, I want OpenID Connect to be what Facebook and Google and others implement that becomes the interoperable identity interchange protocol for the social web.
We’re not even that far away from such a solution. So, to summarize: OpenID + Email Aliasing = Less Spam. The Information Card Ecosystem | Information Cards. Open Identity Exchange. Two tastes better together: Combining OpenID and O. Update: Einar Solbakken has translated this post to Danish. On Friday, David Recordon, one of the original authors of OpenID, released a single-page specification for OpenID Connect, a concept that I outlined on this blog in January before I joined Google. I’m particularly excited about this early proposal because it builds on all the great progress that the community has made recently on a litany of technologies, including OAuth 2.0 and the link-based resource descriptor format (LRDD) and its emerging JSON-based variant (JRD).
But I’m most excited about OpenID Connect because it forces the OpenID community to evaluate the progress we’ve made over the last three years (OpenID 2.0 was introduced in 2007) and to think critically about where we go next, and how we get there, given what the market has indicated it wants. Rearticulating the problem Thus the basic architecture of OpenID concerned itself with establishing identity across contexts (i.e.
The economics of user-centric identity Why?