[foaf-protocols] WebID talk at W3C

Dave Longley dlongley at digitalbazaar.com
Wed Aug 25 03:34:37 CEST 2010


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.

> 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
CTO
Digital Bazaar, Inc.
Phone: 540-961-4469



More information about the foaf-protocols mailing list