[foaf-protocols] WebID talk at W3C

Kingsley Idehen kidehen at openlinksw.com
Wed Aug 25 05:46:07 CEST 2010

  On 8/24/10 11:11 PM, Dave Longley wrote:
> On 08/24/2010 10:03 PM, Kingsley Idehen wrote:
>>  On 8/24/10 9:34 PM, Dave Longley wrote:
>>> On 08/24/2010 08:47 PM, Kingsley Idehen wrote:
>>>>    On 8/24/10 8:11 PM, Dave Longley wrote:
>>>>> On 08/24/2010 05:22 PM, Joe Presbrey wrote:
>>>>>> On Tue, Aug 24, 2010 at 7:19 AM, Kingsley 
>>>>>> Idehen<kidehen at openlinksw.com>    wrote:
>>>>>>>> Great, so apparently there will be 15 minutes to present these 
>>>>>>>> slides.
>>>>>>>> This idea was to follow this by 10 minutes to demonstrate 
>>>>>>>> Manu's solution, under the heading of WebID. I am arguing that 
>>>>>>>> this is a bit much for a solution that we have no 
>>>>>>>> interoperation for, and have not considered. My argument there 
>>>>>>>> is that a 3 minute screencast should be more than enough.
>>>>>>> Sorry, but I still don't get the elevation of Manu's solution to
>>>>>>> definitive demo status re. WebID.
>>>>>>> Manu: no offense intended here, but this simply doesn't feel 
>>>>>>> right at all.
>>>>>> Agreed. I think it would be a sad waste of WebID's 15 minutes to
>>>>>> mention Javascript or Flash.
>>>>>> Maybe I misunderstand but, my view of your JS/Flash is as a 
>>>>>> workaround
>>>>>> for browsers who have not yet refined their SSL client UI. WebID 
>>>>>> needs
>>>>>> to be in the browser. Much of the trust/security of the primary
>>>>>> request is lost when the WebID-authn/TLS process is encapsulated as
>>>>>> JS/Flash subrequests.  +extra round trips, etc.  eek!  Was this
>>>>>> omission on purpose?  OTOH, this is a huge advantage we have over 
>>>>>> the
>>>>>> other authn solutions and should leveraged and mentioned.
>>>>> The JS/Flash is a drop-in replacement for the browser certificate
>>>>> generation/selection UI.
>>>> Fine, but that isn't what WebID protocol is about.
>>> Could you explain how the website you proposed as an alternative 
>>> site (the cheese website) better demonstrates the Web ID protocol?
>>> The JS/Flash demo now does the following:
>>> 1. Allows a user to generate a certificate with a subject 
>>> alternative name URL.
>>> 2. Stores the user's public key and nickname in RDF at the above URL.
>>> 3. Allows the user to select a certificate to login.
>>> 4. Uses TLS to provide the certificate to the server.
>>> 5. The server dereferences the Web ID URL.
>>> *Note: At present the server does not check the public key but this 
>>> has to be verbally described as part of the protocol anyway (it is 
>>> hidden from the user) and is functional elsewhere. Btw, does anyone 
>>> have a link to some php source we can drop into the demo to patch 
>>> this (sparql query+comparing bytes in the public key)? If not, and 
>>> it's *absolutely necessary* it can be added, but will not change 
>>> what the user sees in the demo. This isn't difficult to do but we 
>>> didn't want to reinvent the wheel when we could just cut and paste 
>>> some opensource PHP implementation that already exists. If this is 
>>> really a sticking point we can spend a few hours and resolve it.).
>>> 6. The server returns the certificate and RDF data for display on a 
>>> login page to demonstrate that it was received and the user was 
>>> authenticated.
>> As per the mail I just sent. Cheeses site demonstrates the effects of 
>> WebID.
>> The essence of the WebID value prop. should be the focus of a 15 
>> minute demo:
>> 1. No form based login style authentication
>> 2. Co-existence with other authentication methods e.g. OpenID (where 
>> WebID + OpenID takes away the login style authentication) .
> I don't see any significant difference between a web-form-based login 
> style authentication (e.g. a web page) and a gtk-form-based login 
> style authentication (e.g. firefox). I mean, in so much that both are 
> "forms" that require user input.

Okay, fine that's true.

But do take note of the context re. Firefox. Its the worst of the 
browsers re. Cert. selection UI, but also the one least used by 
end-users. Thus, don't base the Cert. selection UI problem on Firefox.

> I understand that if users were comfortable with the latter then it 
> would become the standard way of authenticating with a website (thus 
> alleviating any work a website has to do to provide a login form) and 
> this is valuable. However, I think, at this stage, it's also valuable, 
> vital even, to demonstrate that this paradigm-shift need not be 
> immediately forced upon users to get them to adopt this new 
> technology. The change can be gradual -- and all of the other benefits 
> of Web ID (linked data, etc.) can be more readily brought to bear 
> without such modern barriers.

But what about Flash. Does everyone like, use, and have flash accepted?

As I said, if UI becomes a topic of discussion, you have a natural segue 
for your innovation as one approach to dealing with the problem. No 
problem there. I would just encourage you to let the session take you to 
that place. Otherwise, other aspects of WebID are more important.

>> Of course, if it so happens that the issue of Cert. generation is 
>> raised alongside the idiosyncratic nature of browsers (primarily 
>> Firefox which isn't a dominant end-user browser), then you have a 
>> natural opening for your innovation. Thus, let the presentation 
>> session in general determine the exposure of your specific 
>> innovation, while the value prop. presentation demo focuses on the 
>> key essence of WebID.
> I understand your point, but I believe showing that this technology 
> can overcome the current barriers and any lag browser vendors might 
> have in implementing proper UIs is essential.

Yes. If the session heads down that path.

> I'm not quite sure, however, what you mean when you say Firefox isn't 
> a dominant end-user browser... it's the second most popular next to IE. 

Yes, but what percentage of its users are non-geeks? Minuscule at best. 
Safari has far more non-geek users.

> Both of which, at present, have the worst/most complicated user 
> experience regarding client-side certificates. Maybe I'm 
> misunderstanding your meaning.
> http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

I stand by my position re. Firefox. Its a geeks browser predominantly.

As for Cert. selection UI, I don't find anything wrong with Windows 
(which IE delegates its Cert. authentication to etc..). Like Mac OS X, 
the Certs. dialogs are clear enough and they let you drill down, 
coherently. Of course, that's my subjective opinion (like yours) :-)

>> Kingsley
>>>> The prime issue here is that you are positioning this effort as 
>>>> holistic
>>>> and definitive re. WebID value prop. which simply isn't accurate or 
>>>> right.
>>>>> Could you please explain what you think the JS/Flash demo is doing 
>>>>> that
>>>>> leads you to conclude that the security of the authentication 
>>>>> process is
>>>>> reduced (and explain how it is reduced)?
>>>> I believe the issue is more about its insertion into the 
>>>> presentation. A
>>>> presentation that's supposed to effectively showcase the WebID
>>>> protocol's value proposition.
>>>> The issue isn't your specific innovation. The issue is putting your
>>>> innovation in appropriate context relative to the WebID protocol in
>>>> general, with regards to the W3C presentation.
>>>> If this is a Pay Swarm + WebID exploitation presentation, different
>>>> matter, but as far as I can tell this is a WebID protocol 
>>>> presentation.
>>>>>> Also agreed with Steph on decentralization !~ availability.
>>>>>> _______________________________________________
>>>>>> foaf-protocols mailing list
>>>>>> foaf-protocols at lists.foaf-project.org
>>>>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> -- 
> Dave Longley
> Digital Bazaar, Inc.
> Phone: 540-961-4469



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100824/9b318e28/attachment.htm 

More information about the foaf-protocols mailing list