[OpenID] is openid 2.0 a lightweight identity system?

[Simon Willison]

On 2/8/07, rob <robyates70 at gmail.com> wrote:
> I understand the trade offs and compromises that need to be made during
> a specs development, but has it drifted away from what I thought was its
> initial mandate, namely to provide a lightweight, i.e. easy to implement
> from scratch, federated identity system (we already have SAML).

I've been struggling with this a lot myself recently. I've invested a
great deal of effort in to explaining OpenID and advocating to as many
people as possible, precisely because the current spec makes so much
sense to me - an identity is a URL, server information is embedded as
HTML (so anyone who can edit HTML can create their own OpenID) and
identity-proving takes place using simple redirects and relatively
straight-forward cryptography.

OpenID 2.0 on the other hand is much tougher to explain. So far I've
been avoiding it - there's only so much you can discuss in a blog
entry, a 15 minute talk or a 5 minute screencast and OpenID 1.1 is a
nicely rounded proposition. I don't think I can avoid discussing
OpenID 2.0 for much longer though, and I have no idea how to tackle
it.

The biggest problem for me is i-names. I know loads of smart people
who are getting excited about OpenID at the moment; I ask them about
i-names and none of them have even heard of them! Outside of the
identity community i-names appear to have almost no penetration or
mindshare at all. Furthermore, having spent a significant amount of
time reading up on them I'm still unconvinced as to their value. I
understand the advantage of i-numbers, but the trade-off in terms of
an entirely new DNS-style managed namespace (not to mention the
$20/year charge for a personal i-name) just doesn't seem to justify
the benefit. I can't explain and advocate them to other people if I'm
not convinced about them myself.

XRDS is tricky as well. OpenID's link-rel tags are simple to
understand and trivial to implement, sticking to the classic HTML
tradition of view-source. XRDS requires accept: headers and XML
parsing and, as Rob mentioned, a 74 page spec. What do we get in
exchange for that added complexity?

I've been thinking about this for a while now, but until now I've
avoided sending my thoughts to the list because I'm certain that this
debate has already been done to death here and that I'm just missing
out on long-term perspective. I'm sending them now because I know that
I'm not alone - when I talk to other developers about OpenID 2.0 they
are shocked at the magnitude of the changes, and I'm at a loss to
explain them myself. From the point of view of an outsider, OpenID 2.0
simply isn't a clear proposition compared to OpenID 1.1.

This community needs to explain the benefits of OpenID 2.0 in totally
transparent terms - in an FAQ, for example. Right now I just don't
have the tools, knowledge or understanding to explain why OpenID 2.0
is a significant improvement on the spec that we have now - and it's
not for a lack of trying.

I really want to believe in and advocate OpenID 2.0, but it simply
isn't the OpenID I fell in love with. I don't want a complicated spec
that's a compromise between many different parties; I want a simple
spec that's easy to explain, easy to implement and proven to work! As
a fan of the original OpenID, it feels a little like OpenID 2.0 is a
bait-and-switch - same name, completely different philosophy.

I mean no disrespect to the people who have worked so hard on OpenID
2.0, but I can't pretend that I buy in to it while I still have these
concerns. Please help me understand its advantages so I can shout them
from the rooftops!

Best regards,

Simon Willison
http://simonwillison.net/