[foaf-protocols] WebID talk at W3C
dlongley at digitalbazaar.com
Wed Aug 25 05:11:36 CEST 2010
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
>>>>>>> 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
>>>>> Maybe I misunderstand but, my view of your JS/Flash is as a
>>>>> for browsers who have not yet refined their SSL client UI. WebID
>>>>> 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
> As per the mail I just sent. Cheeses site demonstrates the effects of
> 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.
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
> 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
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.
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.
Both of which, at present, have the worst/most complicated user
experience regarding client-side certificates. Maybe I'm
misunderstanding your meaning.
>>> The prime issue here is that you are positioning this effort as
>>> and definitive re. WebID value prop. which simply isn't accurate or
>>>> Could you please explain what you think the JS/Flash demo is doing
>>>> 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
Digital Bazaar, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols