[wp-hackers] GSoC 2008 Proposal: Core OpenID Support

[Otto]

On Wed, Mar 19, 2008 at 12:41 PM, Charles <lists07 at wiltgen.net> wrote:
>  As you said, the goal should be to improve the experience of the WordPress
>  user.
>
>  For a good normal-user perspective, I recommend reading "Why OpenID" at
>  <http://openid.yahoo.com/>.  For many "normal" users, ID management is an
>  onerous, persistent and frustrating problem that the WP developer community
>  can either be proactive about or not.

I've read all the info on OpenID, including that one. I'm still
unconvinced. Let's break it down:

OpenID is essentially a single-logon system. You can login using a
unique identifier (in this case a URL), and have it the same across
several sites. What I'm unconvinced of is what such a thing would add
to WordPress in particular.

There's two aspects to this: Being a provider and being a consumer. In
this case, we're specifically talking about WordPress being a
consumer. For the WordPress blog to give other people than the blog
owner the ability to login to the site via OpenID, or otherwise use
OpenID to authenticate to the site in some manner.

There's two aspects to being a consumer as well:
1. Login/Registration
2. Commenting (anon or not)

For case 1, the idea is that you'll be able to login to the site via
OpenID. This only applies to multi-user blogs, of course, because it
doesn't make much sense for a single user blog (especially if the blog
is also a provider). Being a multi-user WordPress standalone blog is
not the most common use case of WordPress. In fact, I'd say it's an
edge case.

For case 2, the idea is that commenters would be able to use OpenID
instead of filling in name/email/url information, or perhaps instead
of registering altogether.

For the latter case, requiring commenters to register also seems like
an edge case, very few blogs (WordPress or not) require user
registration for commenting. In fact, I'd go so far as to say that
this is an argument against OpenID, as it would encourage requiring
users to register on more blogs, since just having an OpenID does not
obviate the need to register on a site, it just provides a single
sign-on system.

The most common use case is anonymous commenting (really
unauthenticated commenting), and OpenID offers nothing at all in this
case. Filling out one field instead of two, but then requiring an
extra step to login/allow the site to receive your credentials via
OpenID seems like a step backwards. Sure, you can create an OpenID
provider that doesn't have this restriction/requirement, but there are
not any of these that I've found other than the anonymous one
mentioned in this thread earlier.

So, what I'm saying here is that OpenID support only offers help to
the edge cases, as I see them. Furthermore, the only real support
offered in favor of it so far is that it would help OpenID adoption,
which is a) not a WordPress problem and b) not something I really
support in the first place. As such, I don't think it's appropriate
for the WordPress core code itselfk, nor something that WordPress
should devote resources and time towards. Not at this time, in any
case.

>  Whether it's a plug-in or not doesn't seem as relevant as whether it's
>  part-and-parcel of WP or not.

On the contrary, this is the same question from two different sides.
Supporting it in the core means, essentially, picking an
implementation and standardizing it. But, making it easier for plugin
systems to support it allows for competition and to let the actual
user base determine what the best implementation is through
popularity.

Look at Tag support, for example. By far, the most popular tagging
plugin was the Ultimate Tag Warrior, and the resulting interface in
WordPress 2.3 bears a striking resemblance to how UTW worked. The
internals are different, to be sure, but the several tagging plugins
developed determined what the users wanted by what they used and stuck
with and that information was used in determining what went into the
core.

As has been noted in this thread already, OpenID is not a particularly
popular plugin. It's not something that WordPress blog owners
generally want and/or use. So it seems like a stretch to say that
putting it in the core at this time makes sense. As Alex said before,
enabling the plugins are not a particularly straightforward task;
perhaps if it was more popular, then the problems would be worked out.

It is not WordPress's place, on the whole, to push "emerging"
technologies. It is WordPress's place to appeal to it's own userbase
and to implement features they want. Not what they say they want, mind
you, but what it is determined that they want through observation.

The best argument for putting something in the core is to make a
plugin for it and make it ubiquitous. When it becomes something that
every blog owner wants and enables, when themes support it by
default... then I'll say it should be in the core. Not before that.

-Otto