Henry’s screencast was a demonstration about how to create WebIDs, and then once created, how to use them to easily log into any WebID-enabled service. I thought that his demo clearly showed the benefits of authentication via WebIDs. Once the WebID was created, he easily logged into a number of sites using different browsers. His screencast should not be the whetstone used to assess the virtues of WebID over OpenID Connect. To do that, we would have to compare his demo to a screencast of creating an OpenID provider service which is a complex process.
So, please do not assume that Henry’s video is just a demonstration of how one uses a WebID to log in. It is not. Instead, it is about creating a WebID from scratch and then using it to log in. Imagine how complex the video about creating and OpenID provider service would be. First, you must create the OpenID service, then purchase a CA certificate for that service, then create your OpenID, then login.
WebID Apples to OpenID Apples
The fair, pertinent comparison is at the stage where both the WebIDs and OpenIDs have been created. So, let’s look at an example scenario. We will assume that our BuddyPress site accepts both WebIDs and OpenIDs as Single-sign On (SSO) solutions.
When a user first visits our fictitious BuddyPress site looking to join, they are presented with three options:
1. Signup for yet another username/password combination. This is the default BuddyPress option.
2. Signup and login using OpenID
3. Signup and login using their WebID
We can assume that some users will come to a given BuddyPress site already with an OpenID or WebID. So, what happens when they choose to use their WebID to signup?
The signup process on our BuddyPress site will attempt to create a new account and then authenticate using the WebID provided by the new user. The process utilizes the self-signed certificate on the user’s browser and the user’s FOAF file which is located within a webspace that the user controls (it could be the user’s blog, for example). Unlike with OpenID Connect, with a WebID, there is no need for a 3rd-party authentication mediator. Authentication via WebIDs decreases security risk and complexity, while making the process more reliable. OpenIDs, on the otherhand, are owned and controlled by third parties–unless a given user has gone through the meticulous process of setting up their own webspace as their personal OpenID Provider.
Here’s a pertinent morsel from the W3C WebID resource page:
Because Web IDs are based on the Domain Name System (DNS), they are more distributed by nature than identifiers issued by a central authority and do not require everyone to sign up to a particular service. If you create your own Web ID, you can also control what information is returned when someone looks up that Web ID.
It is important to understand that OpenID Connect is what is called a federated single-sign on (FSSO) process. It requires a number of entities to function flawlessly to accomplish the authentication process. Single-sign on (SSO) with a FOAF+SSL-enabled WebID is not federated as it is a private process exclusively between the user and the site.
Options for Users Without WebIDs or OpenIDs
However, if a user comes to the site with neither an OpenID or WebID–and they prefer not to create yet another account at yet another website–then they would be given two additional options:
a. Generate a WebID for them (in other words, each given BuddyPress site would become a WebID provider)
b. Send them to a 3rd-party provider where they have to go through the process of creating an OpenID on someone else’s site and then hopefully return to our site to log in
In fact, it would be a relatively straight to automatically generate a WebID for each member of a BuddyPress site. Of course, since some members may already have their own WebID–either created and controlled within their own webspace or obtained via another network provider–it would make more sense to offer that as an additional benefit during the signup process.
Beyond Authentication
Unlike OpenIDs, WebIDs are more than just a username associated with a password and a certificate. They are also associated with a FOAF file which helps facilitate a more accurate representation of a real world Web of Trust. So instead of the Web of Trust relying on you trusting the OpenID Provider (the site), a WebID allows you to trust a circle of friends. This is the way trust is usually mediated in the real world. We trust people, in particular our friends, and only marginally trust institutions.
As an example, if one of our friends says they know someone and are friends with that someone, we have a better recommendation of trust than we would if a 3rd-party mediator was to simply state that, “it appears that the person requesting access to your resources is the person whom they claim to be, although we cannot assure that that is the case.” With FOAF-mediated trust, a user quickly learns which of their fiends in their extended circle are trustworthy and can delete those friends (connections) that fall short on their trust scale. There is no quick or easy way to delete a 3rd-party verifier whose trust becomes compromised. The FOAF file can also provide additional information that the user chooses to share with the world. It can easily be updated, which means relationships can be added or deleted under total control of each user.
There are additional advantages WebIDs offer over other SSO options. Unlike with OpenID Connect, WebIDs can also be used to facilitate authorization via Web Access Control. Of course it would be possible to utilize OpenIDs for authorization as well, but that is currently the role of OAuth. This is a topic for a different thread.
Which One to use?
There is no reason that we cannot offer both OpenID Connect and WebID sign-on options. We are talking about, after all, single-sign on options. There is no requirement that we can only choose one. All WordPress installs will still come with the option for users to register a new, site-specific username and password. I do not see that changing in the future.
SSOs are just another option that facilitate site participation, making a given site potentially more attractive to a wider audience. After all, how many of us want to rack up additional unique usernames and passwords?
In my opinion, the question of which SSO is best for WordPress / BuddyPress is irrelevant. We should work toward enabling both options and let Site Administrators–and ultimately site users–decide which option they prefer to use.
NOTE: Visit this link for a brief discussion of how to foaf+ssl enable your Web 2.0 application. This first part of that section is a slightly different topic as it is about providing WebIDs to a site’s users, not authenticating WebIDs. This is identical to enabling each BuddyPress install to become an OpenID provider. This is a topic we may wish to discuss as well. We could not only have the facilities to process users’ existing WebIDs, but we could also offer the option to generate new WebIDs for those users who do not yet have one. This is relevant for users who do not run, do not manage, thier own personal webspace.
However, the second part of that section is about enabling WebID authentication. It is not a technical discussion as much as a general outline of the steps and processes that must occur.
