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

Kingsley Idehen kidehen at openlinksw.com
Sun Aug 8 16:14:24 CEST 2010

Manu Sporny wrote:
> On 08/07/2010 06:26 PM, Henry Story wrote:
>> There are a couple of your claims above that I think need a little
>> tuning or explaining in more detail.
>> First the claim that WebIDs cannot be created in Internet Explorer is
>> not quite true. IE has an Active X component that comes with the
>> operating system and that is available. Creating a WebID using IE from
>> http://webid.myxwiki.org/ should work, though as I don't have Windows
>> I don't test it that much to tell the truth. Bruno Harbulot wrote a
>> piece of javascript to change the DOM to replace the HTML form with
>> calls to that Active X component. The advantage of doing it that way
>> is that it is going to be faster. Of course that requires Javascript
>> to be enabled on IE, but so does your solution :-)
>> Now the IE Active X solution may have some usability issues, but I
>> think it needs clearly pointing out what those issues are, so that
>> they can be understood clearly,
> I've tried to fix the language in the blog post to state that IE needs
> an ActiveX component to generate a proper certificate in IE.
Depends on what you mean by IE.

The issue is really Windows and the fact the Microsoft consider keygen 

Keygen is considered unsafe because you can load a page from outside the 
host Windows machine that makes critical alterations to the OS (access 
to the Cert. Manager utility is one such example).

Microsoft wants software that works with the Cert. Manger to be signed, 
hence the option to use a signed "one click" applet. This is the same 
mechanism used across the board courtesy of .NET.

Henry: I don't sey keygen support in IE happening anytime soon, even 
with HTML5 support, this is basically why we built our own Cert Manager 
(as per my demos).

>> Secondly you say "you get the peace of mind that if you lose one of
>> your WebIDs, you can always just deactivate it via your WebID provider
>> and generate a new WebID". There is in fact a better way still: you
>> can keep your WebID, and just remove the public key from your public
>> profile. In fact you should be able to have any number of public keys
>> associated with one WebID.
> Hmm, that's what I meant to convey in the blog post, but failed to do
> so. I've fixed up some of the language to make the point you make above,
> and the one I was trying to make initially, more clear.

As per Henry's comments. I have many pubkeys associated with my WebID. 
Thus, if I used a third party devices and forget my private key in 
Firefox (for instance) or Keyring (Mac OS X) or Windows Cert. Manager, 
all I do is go to my Personal Data Space and remove the public keys 
associated with any of those user agents. In an absolute emergency, I 
drop all the pubkeys (just simple deletes via UI) and make a new one for 
whatever user agent I next use.
>> Now when I log in to digital bazaar it asks me for the WebID I already
>> have (I have a few in fact). 
> We think that this is an Apache misconfiguration... we set client-side
> certificate support to optional, so we'll look into this a bit more
> early next week.

You should pick up the WebID of the visiting user agent.

Visit: https://id.myopenlink.net , using a user agent that has one of 
your generated X.509 certs with WebID binding.
>> My browser -- Chromium -- asks me for my
>> client certificate, but then you don't use it! If this system should
>> allow me to use either my flash certificate or my browser certificate
>> this would be great -- if I have already submitted my browser
>> certificate then it should use that. So hopefully we can get it to
>> that point. Especially as me and many people have disabled flash - I
>> just reinstalled it for your site.
> Yes, I think that's quite do-able - shouldn't be difficult to
> accomplish. I'll talk with our engineering team and see what they have
> to say.

Yes, I demonstrate this in all my demos. These are the basic patterns 
we've established via interop fests conducted so far by implementors.

>> What I think you have done is to have tied one more keychain into the
>> WebID system: the flash keychain. Flash is really a browser in a
>> browser. Now it would be even better if flash could use the browser
>> keychain, because then the same keychains could be used for logging in
>> from the browser and flash.
> Unfortunately, we don't currently know of any way of retrieving the
> browser keychain via Flash or Javascript in any sort of reliable fashion
> across all browsers.
> Our current thinking is to entirely abandon the native browser
> client-side certificate generation and selection mechanism because it is
> complicated and broken. 

This isn't a browser issue per se. Its about the Browser and the host OS 

It is now even possible to have Firefox work like IE i.e. rather than 
use keygen have it work directly with the Windows Cert. Manager. I'll 
put out a demo soon that shows how we go for the OS PKI facilities first 
and keygen second (where in this case its browser hosted PKI).

> The browser-based interfaces leave much to be
> desired when viewed from a regular website usability perspective. 

Because this isn't a Browser issue. A Browser is just a piece of 
software that runs within a host OS.  Apple and Microsoft both grok this 
very well and reflect it in their respective implementations of PKI 

> Having
> the mechanism live entirely in HTML+Javascript+Flash allows us to make
> the usability story better when generating and selecting a WebID
> certificate.
> Waiting on the browser manufacturers to improve their client-side
> certificate management UIs will take years. That doesn't mean that
> people wouldn't be able to use the browser-based certificate management
> mechanism for WebID, just that we think that approach is a dead end.

No approach is dead, we just have to understand that you have to deal 
with PKI at two levels: Browser and Host OS. Just give the users options :-)

> -- manu



Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

More information about the foaf-protocols mailing list