This blog can't be viewed on LiveJournal. Instead see


13th Mar 2008

A couple of people have pointed me at this new-fangled Clickpass thing. The general impression I get is that no-one is really sure exactly what it is and what it's for.

Clickpass seems to fundamentally be an OpenID Provider. You can sign up to them and then you can sign in to other sites that support OpenID. They'll give users a 1.1-enabled identifier like which will work in any standard OpenID login form.

Where things get interesting is that they want you to add a special button to your site to allow users to log in without entering their OpenID identifier. This is effectively what "directed identity" achieves in OpenID 2.0, but recall that they have only implemented 1.1. This button submits to their site, not yours. They then determine the identity of the user and fake a request as if the user entered their identifier into your login form. In order for this to work, you must have already entered into a business relationship with Clickpass via their website and told them how your login form works. You'll then bounce the user to the provider for the submitted URL as normal, and they'll bounce them back to your normal return_to endpoint as you'd expect.

The other service they provide is that they'll implement a user registration UI for you. If you wish -- and if you create a few proprietary callbacks for their software to talk to -- you can redirect unrecognised OpenID users over to their enrollment form, and they'll pre-fill it with the user's profile information. Once submitted, they'll then send this data over to your callback so you can create the account with the entered profile information. This is essentially a proprietary re-invention of what the Simple Registration Extension achieves. Similarly, they provide a UI for adding an OpenID login to an existing user account, but in the process they ask the user to submit their account credentials for your site to a form on, which they then proxy through to you. Scary stuff.

These two facets of Clickpass seem to be largely separate. You can implement their crazy button to allow their users to log in without entering their identifier while retaining your own enrollment form. You can also use their enrollment form to sign up users with OpenID Identifiers from other providers. You can also, of course, just accept their identifiers as normal without implementing their crazy button, though they don't make much of an effort to educate their users on how to do this.

It seems to me that almost all of these extra Clickpass features are really just needless re-implementations of existing OpenID standards. Yahoo! has a similar custom login button, but they use OpenID 2.0 Directed Identity to make theirs work. The Simple Registration is able to handle the automatic entry of user profile information even in OpenID 1.1. In order to support this functionality with Clickpass users, you must add to your site extra callback code specifically for Clickpass. The form they provide for associating an OpenID with an existing user account at your site is just downright scary: they're encouraging users to give their credentials from your site to a form in their domain. Even if Clickpass is trustworthy and don't abuse this data, it's still teaching users the bad habit of giving out their account credentials willy-nilly.

I strongly encourage Clickpass to implement OpenID 2.0 with directed identity and the simple registration extension. This will make it far easier for sites to support Clickpass users, using the existing infrastructure they have to handle standard OpenID providers. It shouldn't be necessary to get an account with Clickpass just to accept their identifiers in a user-friendly way. They would also benefit from more instructions at their site on how to deal with OpenID forms without a Clickpass-specific login button; right now they've got nowhere near the critical mass for most sites to consider a special case for them as they might for AOL, Yahoo! or LiveJournal.


  • Nice Review

    Great write up and analysis of the Clickpass service. Personally I use ClaimID as my OpenID provider and it does a really good job, for me. Thanks again for the great information.
    By ext_89738 at 11:35 am on 14th Mar 2008
  • Response from Clickpass

    HI Martin,

    I am Immad, CTO of Clickpas.

    Thanks for checking out Clickpass. You have obviously taken time out to fully understand what Clickpass does before posting and thats much appreciated. Your two paragraph is probably more succinct then anything we have written.

    To put this into context, we started Clickpass in June (before OpenID 2.0), and with the main purpose of making OpenID a more user friendly experience, while keeping within the standard as much as possible. So to answer your concerns:

    "I strongly encourage Clickpass to implement OpenID 2.0"

    We started before OpenID 2.0 was launched, also we weren't sure how fast it would get adopted and there are definitely some frameworks where the libraries are still not in place. Having said that I am really keen to implement Clickpass as an OpenID 2.0 provider and its at the top of my priority list, hopefully we will have something out soon.

    The last thing to say about the Clickpass button is that the idea was very much to allow people to use whatever OpenID they want to use with it, or let us manage there various OpenIDs at sites. We have had a lot of people tell us that its a good solution, and we have shown it a lot of people, even people who don't know OpenID and they have been very happy with the experience.

    You are correct to separate the enrollment UI as completely separate to the Clickpass button.

    Firstly I completely agree, our solution is not ideal. Ideally I would prefer to not ask user for their passwords to third party services and ideally I would like to use the Simple Registration standard. And We are working on coming up solutions to this. But firstly why we did it this way:

    Most significant websites have existing user accounts, even new ones that role out will most likely keep username/password systems in place, but what we found was that websites don't deal with merging and signing up well at all. This puts off people trying OpenID. If you try out how Plaxo or Magnolia (two of the better implemented versions) do it and imagine going through that procedure without knowing in-depth what OpenID is you will see our point.

    - This led us to make the merge screen. Again ideally we would like to not be asking for usernames/passwords for third parties, but this was the quickest and simplest way of doing it, most users are already trained by facebook and other services so we didn't think we would be making a big dent in that process. I think we can probably come up with a better solution in the future using OAuth.

    - On Simple Registration. I am actually looking at a way of doing signup using SREG for Plaxo. The reason we avoided it, was that it didn't quite make sense to ask the user to send that information until we actually know they want to signup for the service and the way Simple Registration was working on other providers was confusing to users. Will let you know when we have a better solution for this.

    I think we can do better at explaining some of these decisions on our website, and we will be launching a blog today to help. I hope we can continue to adapt and come up with more satisfying ways of achieving ease of use. I would love to hear more feedback from you and what other ideas you might have.


    By ext_89796 at 07:33 pm on 14th Mar 2008
    • Re: Response from Clickpass

      Hi Immad. Thanks for taking the time to respond. As I'm sure you've seen now, I've responded to your message on the OpenID General mailing list before I noticed that you had responded here. For the benefit of anyone else who comes across this weblog entry, I'll link here to my message on the mailing list. Specifically it is about how you might integrate SREG into your signup user flow.

      By Martin Atkins at 01:53 pm on 15th Mar 2008
  • The Registration screen

    Hi Martin,

    I've been meaning to reply to this for a couple of days now but have been snowed under with dealing with launch.

    I know that Immad's been getting your advice and working through some of the issues in the OpenID mailing list. You've obviously taken the time to figure out Clickpass well and we appreciate the analysis (although we're obv a bit sad about your banner ;).

    There was another reason why we couldn't use SReg (or at least needed something in addition to it). This was that at signup to an RP we allow the RP to display validation errors directly into the registration form (without having to change scene and bounce to their own site).

    We've always wanted to make sign-up as smooth as possible and doing the errors this way allowed us to reduce the drop-off rate for RP's during registration. We felt that doing this error display using SReg as the precursor would simply end up with SReg + a new protocol suggestion as well as tonnes of round trips. We are right now working with Joseph to figure this all out for Plaxo.

    It's not easy but we're certainly open to suggestions. If we can use standard protocols we would *much* rather do that as we know it makes integration and interoperability much easier (we made sure to at least use the VCard namespace for our parameters)- we are developers too!
    By ext_89714 at 11:57 pm on 15th Mar 2008
  • What problem does Clickpass solve?

    The only difference between the Clickpass service and the normal Openid login is that Clickpass gives you a fancy button and you don't have to remember your identity url.

    I don't know about you, but I find no difficulty remembering ONE username, ONE password and ONE url for all of my accounts.

    In addition, Clickpass makes things MORE complicated - first I have to sign up as an Openid consumer, THEN I have to create a Clickpass account. So now I have to remember even more accounts than I would if I just used Openid in the traditional manner.

    What problem does Clickpass solve?
    By ext_90248 at 01:59 am on 18th Mar 2008