[foaf-protocols] WebID breakthrough - pure Javascript+Flash implementation

Henry Story henry.story at gmail.com
Mon Aug 9 10:57:15 CEST 2010

On 9 Aug 2010, at 05:08, Manu Sporny wrote:
> On 08/08/2010 09:57 AM, Kingsley Idehen wrote:
>> The user interaction is simple:
>> 1. Go to: https://id.myopenlink.net
>> 2. Register with your existing WebID or get a new account
>> 3. Edit your Profile using the Profile Manager (at least add your email
>> address to your profile)
>> 4. Use the "X.509" tab under "Security" to generate your X.509 Cert that
>> includes your WebID (remember once you have an account you have a WebID,
>> Profile Page URL, and an OpenID URL (all hooked together in conventional
>> Linked Data style)
>> 5. Save the generated Cert. to your Profile (don't forget to hatch the
>> "enable WebID login" option)
>> 6. Save and Exit Profile Manager
>> 7. Visit a WebID or OpenID based space on the Web from Windows, Mac OS
>> X, Linux, or any other Unix Platform.
> Kingsley, I'll respond to your other points in another e-mail. I wanted
> to draw attention to the procedure you describe above. This is a perfect
> example of the problem we wanted to highlight when putting together the
> WebID demo we recently released. Compare the sequence above with how we
> create accounts in websites today:
> 1. Click create account.
> 2. Fill out username, e-mail address and password.

You are being completely unfair here Manu.

A. Create a new Account the traditional Way

First login with a normal web site login is more complex than you describe, if we are to stay at the same level of detail as Kingsley's description:

1. Go to some website http://site.com/
2. click create account
3. fill out username, email, password
   3.1 The password you filled out is not secure fill it out again
4. Click submit
5. receive email
6. click on received email to confirm it
7. Login with new username
8. The browser will ask you to remember the password in a modern browser
   otherwise write it down on a piece of paper (because you should of course
   never reuse the same password twice)

And that is the minimal version. If you try to make a Social Network account, you
also have to give your gmail password away, import your friends, friend them one by one again on the SN, ... All of this will no longer be required by WebID and foaf enabled sites. 

Secondly Kingsley's description is confusing two things: making your first and hopefully only WebID account and signing onto a new site with your WebID when you don't have an account there.

So let us sift these two strands apart so we can compare like with like

B. Create a new account with WebID

a. From Scratch

1. Go to some website http://site.com/
2. click create account
3. Fill in cert username (the Distinguished Name)
4. Click submit (this adds your certificate to your keychain)

Good so now in the above the site does not know your e-mail and you don't have
a way to login from a different computer using some password mechanism. But we can see that minimally, creating a WebID account is much simpler. 

But really if this is going to be your main WebID account, you are going to fill in your e-mail, verify it, add your friends, etc, etc.... 

b. with an existing account

But let us be realistic here: most people already have set up those accounts, with friend lists and so on. So the scenario that people most people will be in is the following. Their Social Networking account enables WebID on the site. All they need to do is

1. enter a Distinguished Name
2. Click "create WebID"

The above two step process is what will transform the Social Networking account into a Social Web account. Clearly this cannot even be compared in simplicity to what passwords just cannot do.

C. Sign in to a site that is not your WebID Provider

1. Go to the site (of course)
2. click login
3. Select certificate in your browser

You are done. So logging into any web site on the internet is now minimally a 3 *click* process, and with this you can get your social network to come along. If you want the site you are logging into to get more than the public information you need to friend that site, which will be another few clicks.

> Now, sign in:
> 1. Enter username and password.

Sign in where Manu? Let us compare the two processes again, as once more you are not comparing like with like.

D. Logging in to the site the username and password is for

a. If you had to type the password in by hand

1. Go to the site
2. Click Login
3. fill in username and password
   3.1 type your username by pressing each character in the order of the username   
   3.2 press tab to change to the password field
   3.3 type your password by pressing each character in the order of the characters in the password
   3.4 click submit

So instead of 3 clicks you have something closer to 20 keystrokes.

b. with in browser password management

1. Go to the site
2. Click Login
3. username and password will be filled in, though you sometimes need
   to validate the username, then click Login.

E. Logging in to a site to which you have never been

   You just can't do that with username password system.

Well with OpenId you get as close as one could get.

1. Go to the site
2. Click Login with OpenID button
3. type the URL, click login
4. be redirected to your OpenId page (which could use SSL to identify you and just redirect you, but usually requires logging in as above with version D.b. 

And furthermore here you do not get the option of getting your social network to come along with you.

So the main advantage of WebId is not logging into the site your are logged into, but logging into every other site. But even when logging into one's own site it is a small simplification of the current system.

> Both you and Henry seem to be commenting about WebID from the standpoint
> of how easy it is to manage X509 certificates now. The point that I'm
> trying to make is that if we talk about managing X509 certificates /at
> all/ for /any/ WebID interaction, we're going to thoroughly confuse the
> majority of people that use the Web. WebID is not going to be adopted
> very rapidly (or at all) because it is more complicated than what we do
> on websites today.

That is because you have not yet got a situation where WebID shines: the one where you allow me, with my own WebID to login to your site. You need to compare the complexity of A to that of E.

If you are just trying to replace username password, without perceivingthe global login problem, you won't see much of an improvement.

> One of the points of our demo was to highlight that WebID is competing
> against traditional login. When traditional account creation is a 2 step
> process at best, and a 4 step process at worst - having a 7 step process
> (as you outline above for WebID) won't be received well by the general
> Web community.

So apart from my disagreement with you on the way you count your steps I disagree fundamentally about where the WebId competition is. WebID is not competing against traditional login, it is competing where traditional login does not work.

So in terms of steps we have traditional account creation which is at the very least an 8 step process as described in A, but is closer to a 100 step process - and it gets richer at every iteration. So really you are comparing 8 to infinity long step process to a 3 step process described in C. Every time you use your social network and build on it the value of WebID grows.

> That is not to say that experts should be stopped from managing their
> own certificates, quite the contrary, we should support experts... but
> also understand that they are the minority and WebID cannot be
> successful by catering to or designing for experts.

No idea why you think one has to be an expert to manage one's certificates.

> Here are a few anti-patterns for WebID as far as I see it:
> 1. Requiring plugins of any kind that are not in over 90% of all
>   browsers. Flash is a plugin, but it is available in over 90% of all
>   browsers.

WebID requires no plugin!
Flash is a plugin and is no longer available on two very important platforms: the ipad and the iphone. Many people disable Flash as it uses up a lot of unecessary CPU with silly adds.

> 2. Requiring browser features that are not already widely deployed.

WebID browser features are widely deployed.
Much more widely deployed than Flash or fast javascipt to tell the truth.

> 3. Depending on browser/OS features that could confuse the user
>   experience - like OS-native X509 Certificate generation.

People tend to use one browser. So it is just a question of having a good introduction to them and of explaining the benefits. As I pointed out, pretty much every browser certificate selection apart from Firefox is easy to understand.


> The main point of the demo was to demonstrate that WebID doesn't need
> any of the OS/browser technologies that this community believed were
> necessary to implement WebID in the browser.

  yes that is cool.
  But I don't see that the other points you are making follow. Most of all I don't see that this is an user experience improvement of the depth that you make it out to be.

> Furthermore, I think it would be a mistake to choose a technology
> solution that is more complicated than regular account creation and
> username/password login is at the moment. The current state of managing
> X509 certificates via the browser or the OS falls into this category.

People often repeat this point, but when I analyse the argument it falls apart.

> That said, I do think we should support the traditional OS/browser-based
> WebID experience, but understand that that experience is for experts and
> will confuse the general public. If we are going to start presenting
> this work to people like Google, Twitter and Facebook - we need to show
> them something simpler than a demo that requires them to manage their
> OS/browser-native X509 certificates.

  I really do disagree that this will confuse the public. This is what security people all say because they have not used WebID, and because their experience is of normal certificate creation which indeed is confusing and expensive. When you help them go through the points above, they slowly, and usually with a lot of reticence, retract their points.

  Thanks for helping me make a lot of this more explicit.


> -- manu
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: WebID - Universal Login for the Web
> http://blog.digitalbazaar.com/2010/08/07/webid/2/
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list