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

Manu Sporny msporny at digitalbazaar.com
Mon Aug 9 05:52:53 CEST 2010

On 08/08/2010 06:16 AM, Henry Story wrote:
>> 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.
> Ok, but it is not really a big deal to deal with, as that ActiveX
> component comes
> with the Operating System. So from the users perspective there is no big
> issue there. From the coders perspective it is not such a big issue.
> It am not sure how long IE will be before it integrates <keygen>
> either given that it is part of html5 now.

Yes, we can create the jQuery of WebID. My concern revolves more around
the notion that this community would prefer to use the OS/browser
certificate manager over a more unified, simpler to use, purely
in-browser experience.

> Has your  engineering team  created themselves a WebID certificate
> from one of the other providers? If they get one one from webid.myxwiki.org or
> from foaf.me you will see this behavior a lot more clearly.

One of them was doing this today, I'll see if they've played around with
WebID on xwiki yet.

> So the idea there would be to do it as follows:
>   - if the client sends the certificate on clicking your login button
> then don't show the flash applet
>   - if you end up displaying the flash applet then you can use the flash method
>     (that will probably end up on the NASCAR page)

We're thinking of getting rid of the NASCAR page by just using XAuth...
that way, your browser automatically knows your WebID provider and can
automatically display the certificate management screen easily.

>> 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.
> Does it work in 80% of the cases? 

It currently works in 0% of the cases, AFAIK. There is no mechanism to
read the browser keychain in Flash.

>> Our current thinking is to entirely abandon the native browser
>> client-side certificate generation and selection mechanism because it is
>> complicated and broken.
> I think we have found that for all desktop browser certificate
> creation is quite easy. Other than
> Internet Explorer, which I think works, but does require more detailed
> looking at.

It's not clicking the "Create Certificate" button that I'm concerned
about. It is the certificate selection screen and the fact that the user
is provided a dialog that requires them to understand that they need to
select a certificate to connect to a website. This is a really foreign
concept to the vast majority of people that use the Web. It requires
them to know about how WebID works, which is going to negatively impact
WebID adoption.

> Which browser do you find the selection mechanism to be  deeply broken with ?

All of them, because there is no way for us to hook in to the process
and explain what is going on. It requires people to understand how WebID
works, understand that there is an X509 certificate involved, which is
an awful browsing experience for a non-technical web user.

> If you check the following
>     http://esw.w3.org/Foaf%2Bssl/Clients/CertSelection
> I think it is clear that it is just Firefox that is really ugly.

All of them are ugly - "Select a certificate". How do you think
non-technical people will react to that screen?

>> The browser-based interfaces leave much to be
>> desired when viewed from a regular website usability perspective. Having
>> the mechanism live entirely in HTML+Javascript+Flash allows us to make
>> the usability story better when generating and selecting a WebID
>> certificate.
> Well the story is a bit more complex. You now are dependent on Flash,
> a technology that Apple is pushing out of some of the most popular devices.

The devices that don't support Flash can use the in-browser,
certificate-based mechanism.

We are only dependent on Flash for the cross-domain stuff and local
storage. Once CORS and LocalStorage are widely deployed, we can switch
to that. Flash is a temporary part of the stack.

> And it relies on very fast javascript engines, which means that unless
> the browser
> is post Chrome, it won't be seriously useable, being way too slow.

Not true - we could do the certificate generation in Flash (which has a
very performant ECMAScript engine). Or we could do the certificate
generation piece-meal, giving control of the Javascript loop back to the
browser every second (or once every work item is completed) to ensure
that dialog won't show up. There are multiple technical solutions to the
key generation issue in Javascript - all of them can be implemented easily.

As for the rest of the TLS communication - it's fast enough to not be
noticeable in all post-2008 Javascript engines.

>> 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.
> I think we need to find a way to properly integrate this discovery
> into the WebID stack.
> So for example if I am happy with browser based authentication, it
> should work just
> as well with that.

I agree, but know that we're designing for experts at that point.
Browser-based authentication will be very confusing for non-technical
Web people.

> Here is a question: what happens when Flash requests an https URL
> which requires client side certification optionally? 

Flash only provides the raw socket interface, all TLS processing is
performed in Javascript. So, the Javascript can do whatever we want it to.

> Does the browser certificate selection
> mechanism open, or does the flash keychain get called. 

We haven't tested this yet, but the current thinking is that we
misconfigured Apache and if the server requires optional client-side
certificates, the browser certificate selection dialog isn't displayed.
We still need to test this theory.

> Does flash have a keychain? Or are
> you just creating a parallel keychain in code, and saving that to 
> your hard drive?

Flash doesn't have the concept of a keychain, AFAIK. We're using Flash
local storage to store the certificate. One positive side-effect of
using Flash is that your WebIDs are all accessible to any browser that
uses the Flash Runtime. So, Chrome, IE, Safari, Firefox and Opera all
share the same Flash local storage. So, if you create a WebID in Chrome,
the same WebID can be used in IE on the same machine.

This is a benefit that you do not have if you use keygen and the
browser-native certificate management.

> On a different topic, as I as reading the end of your blog I see you
> write the following as  something to
> do:
> "Ensuring that the public keys in the client certificate match the
> ones published by the WebID URL"
> That sounds like you are not verifying the WebID yet, which seems to
> me to mean that it is not yet a WebID.

Yes, that is currently missing and it'll be implemented in time.
Obviously verifying the public key located at the WebID URL must be
performed to be able to trust the Identification Agent.

> Btw, is there a page where we can see the RDF for a WebID?

Not yet, because we don't generate it yet. It'll be generated in time as
we flesh out the code base.

> I think the first thing to do would be to get your site running so it
> interoperates with all the existing WebID services
> we have. This will give your engineers a bit of a feel for what we are
> doing I think, and  how this system is meant to work. 

Hmm... I think that you might be missing the point of what we were
attempting to point out. Perhaps we didn't make it very clear in the
blog post or demo: we don't want to have to depend on browser-based
certificate management mechanisms because they provide, IMHO, awful
WebID experiences.

The demo was primarily intended to prove that one doesn't need to depend
on browser-based certificate management mechanisms.

Interoperability with existing WebID services is easy - getting the user
experience right, as far as we see it, is the hard part.

> I think that once they have done that then it will also be easier for
> us to think of ways together of solving some of the issues that you
> are more concerned with. 

I don't think that interoperability is the main concern here - at least,
I feel that interoperability is a must and switching between a
native-browser-based or javascript-based WebID experience is achievable.

In any case, we can talk more about this on the call - just wanted to
outline that we have more options to implement WebID now than we had
last week... and that's a good thing :)

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: WebID - Universal Login for the Web

More information about the foaf-protocols mailing list