kidehen at openlinksw.com
Mon Aug 9 14:16:05 CEST 2010
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.
> Now, sign in:
> 1. Enter username and password.
> 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.
No I am commenting about the fundamental workflow.
My demos and comments are focused on elimination of username and
password tedium via use of Certificates that bear WebIDs. The thing
about Certificates is that as alternatives to username and passwords
they've existed forever, their broad adoption has been impeded by PKI
management tedium and the CA closed network. Thus, highlighting X.509
generation simplicity ultimately comes into play.
For WebID protocol implementors we have a general commitment to
eliminate the aforementioned PKI management tedium.
Naturally, we don't have to put PKI at the front of our storyline, but
we also have to accept that we cannot eliminate the matter all together.
Personally, I believe in empowering users via technology + user
interaction patterns that demystifies the erstwhile mysterious :-)
> One of the points of our demo was to highlight that WebID is competing
> against traditional login.
Yes, but there is a little void there. You can't go directly to WebID
(at this stage) without going through OpenID. In my experience, this
problem is being solved in stages:
1. OpenID - one place for username and password authentication and
mechanism for attribute exchange
2. OpenID+WebID -- above without username and password based authentication
3. WebID -- above + the ACLs en route to ReadWriteWeb .
> 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.
> 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.
We simplify the process of eliminating usernames and passwords by
reintroducing the time tested alternative without traditional problems.
The concept of PKI has suffered primarily because of the user
interaction patterns associated with its use. Even for the technical,
the process has been woefully painful.
> 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
Me: no plugins .
> 2. Requiring browser features that are not already widely deployed.
understanding the role of the browser relative to its host OS and
ensuring WebID solutions incorporate this reality. The Browser is just a
piece of software, one of many ways of working with WebIDs. We must have
1. Operating System -- Keyring Manger (Mac OS X) and Cert. Manager
(Windows) via keygen or directly depending what Browsers implement
2. Browsers -- browser hosted PKI like Firefox and Opera .
> 3. Depending on browser/OS features that could confuse the user
> experience - like OS-native X509 Certificate generation.
Do not make assumptions about user capabilities. A simple application
(as we've implemented) re. Windows works fine and make the subject
matter of Certification Generation crystal clear. The same applies to
Mac OS X by simply leveraging keygen as exemplified by Safari and
eventually Chrome (for Mac OS X).
We have a platform with a "Generate" button, and via that button we deal
1. OS PKI if directly accessible
2. Browser PKI if the only option.
Alternatively on Windows, a user can just run our Cert. Manager Wizard.
On Mac OS X you don't need to do this.
> 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.
Well, it does.
Flash plugin is an addition to the mix, but it isn't mutually exclusive
to the other approaches in place.
> 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.
Sorry, but you are jumping to very subjective conclusions about various
solutions in this space.
Bottom line, we are building solutions (user interaction patterns vary)
that enable end users to:
1. Make a Certificate that bears their WebID
2. Use the Certificate with browsers and other user agents for
authenticated access to data across HTTP based data spaces.
> The current state of managing
> X509 certificates via the browser or the OS falls into this category.
I don't agree.
My only regret is that I floated the idea of have a WebID mean: Personal
URI + X.509 Cert, as a mechanism toning down the X.509 aspect of this
innovative solution. Unfortunately, the dimension of my concern wasn't
really clear to the foaf+ssl community at the time of my suggesting, so
it was accepted.
If we did revert to also having WebID (as opposed to WebID Protocol)
mean: Personal URI + X.509, I believe your concerns would be allayed.
> 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.
No, user interaction patterns by solution providers should eliminate the
"expert level" perception of X.509 cert generation. This is why we have
a Wizard. One that comes into the user interaction as the point where
you are seeking to associate your WebID with a Public Key within the
confines of your Personal Data Space.
> 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.
Other demos that I have scheduled will more than do that. My initial
demos where very much first cuts to demonstrate that we have the pieces
in place, and that we can use OpenID+WebID to demonstrate key value.
My ultimate demo is about getting yourself a WebID in 5 minutes or less
across any platform, and then showing the power of WebID driven ACLs and
Pingers :-) The more implementations the easier it becomes for me to
make these demos. I don't want to have the demos totally based on our
> -- manu
President & CEO
More information about the foaf-protocols