Why OpenID Attribute Exchange is a lousy idea

Attribute Exchange is a lovely idea. It happens like this: when you log in, the application you’re logging into asks the application that holds your account whether it knows about certain pieces of arbitrary data about you. Things like your website address, Twitter account, and so on. The smart thing is that, like OpenDD and some other formats, it doesn’t mandate the data an application can ask for. If your account holds your favourite kind of bread, the application you’re logging into can ask for it. This kind of generalised profile transmission is one of the things that will eventually form the foundation of the open web.

OpenID is also a great idea. When you want to log into an application, you tell it about where you keep your main account, and through behind-the-scenes magic (and a security check with your account holder), you’re logged in. It’s lightweight, simple, and has implications not just for the commercial web (where end users don’t currently see the need), but also loosely bound intranet solutions and situations where you want several locally stored web-based applications to use the same login.

So Attribute Exchange is great, and OpenID is great.

The problem for me is that, combined, they’re significantly less flexible than they would be as two separate entities that happened to work well together. For very legitimate reasons, an application provider may have to use BBauth, Shibboleth or some other standard to authenticate accounts across web-based applications. Perhaps some of these standards also has a way to move attributes across from one application to another. Nonetheless, if there was a single standard attribute exchange standard that you could use no matter how you authenticated, the barrier to entry would be much lower, and the standard of generally available code libraries to perform the task would be much higher. (The more eyeballs, the better the code, or so the theory goes.)

When Brad Fitzpatrick announced it, though, it was purely a specification for logging in, originally named Yet Another Distributed Identity System, and he’s been semi-publicly skeptical about the extensions. I think this makes sense. I also agree that OpenID will come into its own when you add an attribute exchange (and service discovery) layer over the top, but there’s no need for this to be rolled directly into the one authentication standard. Just because two ideas make sense when they’re joined together, you don’t have to glue them together into a single specification.

I’d like to advocate a policy of “small pieces, loosely joined” when it comes to open data formats. If each format does one thing really well, we can use them in lots of different combinations without fear of breaking something. More freedom for the programmer means more application possibilities and a better market.






Leave a Reply

Your email address will not be published. Required fields are marked *