henry.story at gmail.com
Sun Aug 8 12:16:27 CEST 2010
On Sun, Aug 8, 2010 at 6:24 AM, Manu Sporny <msporny at digitalbazaar.com> 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
>> calls to that Active X component. The advantage of doing it that way
>> 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.
Ok, but it is not really a big deal to deal with, as that ActiveX
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.
>> 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.
Yes, that is more like what webid.myxwiki.org provides - except that I have not
implemented the easy to delete keys functionality there, something
that would come
>> 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.
That is indeed the right thing to do. It means that if the browser has
the browser can ask the user to select one, which it will then send.
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.
>> 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.
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)
>> 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
> across all browsers.
Does it work in 80% of the cases? Perhaps this is a case of solving it in a case
cross browser incompatibilities. It is ugly, but once the work is
done, most people
don't seem to care.
> 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
Which browser do you find the selection mechanism to be deeply broken with ?
If you check the following
I think it is clear that it is just Firefox that is really ugly.
> The browser-based interfaces leave much to be
> desired when viewed from a regular website usability perspective. Having
> the usability story better when generating and selecting a WebID
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.
is post Chrome, it won't be seriously useable, being way too slow.
> 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.
Here is a question: what happens when Flash requests an https URL
which requires client
side certification optionally? Does the browser certificate selection
mechanism open, or
does the flash keychain get called. Does flash have a keychain? Or are
you just creating
a parallel keychain in code, and saving that to your hard drive?
On a different topic, as I as reading the end of your blog I see you
write the following as something to
"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.
Btw, is there a page where we can see the RDF for a WebID?
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. 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. Thinking in linked
data terms is a paradigm shift, and the best way to get to understand
a new paradigm in my opinion is to
work within it.
Talk to you on Tuesday at 5pm London time
> -- manu
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: WebID - Universal Login for the Web
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols