Skip to:
Content
Pages
Categories
Search
Top
Bottom

WebID versus OpenID Connect

  • Avatar of Arx Poetica
    Arx Poetica
    Participant

    @arxpoetica

    Okay, I’m breaking this one out into it’s own thread (that is, a discussion about which identity protocol best fits BuddyPress), as there’s already been some discussion regarding the merits of either or both.

    But first, a primer. Anyone coming to this conversation might want to read some of these external posts:

    http://esw.w3.org/WebID
    http://blogs.sun.com/bblfish/entry/what_does_foaf_ssl_give
    http://factoryjoe.com/blog/2010/05/16/combing-openid-and-oauth-with-openid-connect/

    It would also be advised to read the forum threads titled “Resources for Members” and “Priority of Protocols & Purposes, etc. (case studies?)” for further priming.

    (One quick note: I do expect other protocols to bleed into this one, especially discovery-related protocols (WRAP, XAuth, WebFinger?), but if discussion gets too dense in another area, lets try and break it off into another thread.)

    So, to begin things, there has been some previous discussion about what technologies are best suited for identity. (Specifically, WebID versus OpenID Connect.) (Note it’s now being referred to by the community as OpenID Connect, and a spec is being reworked along those lines.) I believe @jeffsayre favors WebID due to the implicit strength of built-in technology. I believe part of the reasoning (and he’ll have to speak to this as I can’t really do it for him) is that the technology already exists and it follows a more powerful, simple system. I would argue, after watching this link that he posted on Twitter ( http://www.youtube.com/watch?v=8iZPJBpI2Po ) that it is anything but simple, especially from a usability point of view, and that OpenID Connect is working more toward a viable simple solution.

    Nothing here is perfect (yet), and I expect that (funny as this may seem) the identity will be one of the last pieces to actually fit into WP/BP as a social stack protocol. (We’re actually more ready to implement other protocols, such as Activity Streams, PoCo, and OAuth 2.0). However, this also will prove to be one of the more important decisions made. In framing my own preference for going with OpenID Connect (perhaps coupled w/ WebID?), I submit the following questions to prod discussion:

    1. What protocol will actually be the most simple and usable? (I do think this is the most important question, despite other technology concerns)
    2. Adoption rate: Will a larger community support WebID? Should we go with OpenID Connect because it is more popular?
    3. What are the key technology differences, and why is one better than the other (be as specific as possible)?
    also
    4. Can they be coupled in any meaningful way? Is it possible to get the best of both worlds?

    Let’s use this thread to iron out which identity protocol we think will be best, and once we’ve decided on one, we’ll open another thread for how to implement such a thing.

Viewing 1 replies (of 1 total)
  • Avatar of Jeff Sayre
    Jeff Sayre
    Participant

    @jeffsayre

    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.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.