[foaf-protocols] WebID talk at W3C - WebId+Flash

Kingsley Idehen kidehen at openlinksw.com
Wed Aug 25 05:12:45 CEST 2010

  On 8/24/10 10:18 PM, Sarven Capadisli wrote:
> On Tue, 2010-08-24 at 21:53 -0400, Kingsley Idehen wrote:
>> On 8/24/10 9:13 PM, Dave Longley wrote:
>>> On 08/24/2010 08:11 PM, Henry Story wrote:
>>>> There is still a lot we need to understand about the WebId+Flash protocol. I do think there could be something very interesting there btw. But we need to understand the whole idea much better.
>>>> Here are a few issues that came up recently
>>>> If I go to
>>>>> https://webid.digitalbazaar.com/manage/
>>>> It tells me that my webid is
>>>>      http://webid.digitalbazaar.com/demo/ids/1944828261
>>>> But that URL does not lead anywhere
>>> This was not originally part of the demonstration. Since this had been
>>> proven by other Web ID demos it was omitted because it would just be
>>> repeating what we already knew worked properly. The Web ID
>>> authentication process can be broken down like so:
>>> Client-side:
>>> 1. Certificate generation.
>>> 2. Certificate selection.
>>> 3. TLS Certificate authentication (presentation of a certificate within
>>> TLS).
>>> Server-side:
>>> 1. Dereferencing the Web ID URL, doing sparql query to get the public
>>> key and compare it with the one presented by the client, etc.
>>> The demo was meant to show the *user experience* of using a Web ID to
>>> authenticate and prove that it was possible to replace the client-side
>>> part of Web ID with JS/Flash (instead of whatever UI your particular web
>>> browser used). This user experience, as far as typical authentication is
>>> concerned, does not change regardless of the server-side authentication
>>> process.
>> Yes, but is the user experience the key point re. W3C presentation?
>> I see and grok your innovation re. negating the browser and its UI
>> idiosyncrasies, and this is indeed a cool innovation. It just isn't the
>> most important thing re. WebID value prop. to the W3C.
>>> For instance, if I were to go to the cheese website that Kingsley
>>> offered as an example of Web ID and selected a Web ID using my web
>>> browser, I would not see anything happening other than an interaction
>>> with my browser UI. That would be my user experience.
>> That's the beauty of the link and WebID. It's Jedi technology (like most
>> of HTTP).
>> You entered a data space, it recognized you (in a verifiable way) then
>> let you do something in the space.
>> WebID is about eliminating the authentication form, completely, as user
>> agents explore data spaces on the Web (social or anti social).
>>> If you log into the fake "socialswarm" website, you only see the UI that
>>> is driven with JS and Flash. What happens on the server side is nearly
>>> identical in both processes and, for neither of them, does the user see
>>> what is happening.
>> You shouldn't really have to log in. The data space has its rules about
>> who comes in and what they can do. Its like a party, the data space
>> provider might give the bouncer specific instructions about invitees and
>> how they are verified etc..
>> Cheesecake is a very simple example of the pattern I describe. Sociality
>> is driven by clusters that form around "objects" basically "objects of
>> sociality". This is what we do everyday, we cluster around topics of
>> interest re. conversations. Thus, in a social web we should reflect
>> social society i.e., making and participating in conversations, with the
>> option to do so with people we trust etc..
>> You see "login" is really a sort of anti pattern re. WebID. It should
>> only surface when WebID verification fails i.e, the data space drops to
>> the next best option which would be the login and forms approach.
>>> The JS/Flash demo guides someone who is new to Web ID through what their
>>> experience would be if they were to authenticate themselves using a Web
>>> ID that they generated. It does not cover storing information in their
>>> profile using RDF data. In fact, the typical user is never going to know
>>> anything about RDF data and they would be guided via some user interface
>>> on a website that allowed them to enter whatever data was appropriate to
>>> their Web ID. The RDF details would be abstracted away from their view.
>> As per comments above. They don't need to know anything about logins
>> either. They just go to places and do stuff in line with the data space
>> providers terms re. their data space.
> I don't wish to side track the discussion as this probably deserves its
> own thread, but, I wanted to quickly mention an user interaction that's
> briefly coming up in discussions:
> The idea of users being automatically signed-in.
> The first reason that comes to my mind as to why that may not be ideal
> is that, users sometimes want to navigate anonymously.
> I hope I didn't misinterpret you (and others) here, but I think
> distinguishing between "type of" logins, and "being" logged in is
> important.
> -Sarven

Nice point!

This is an important aspect of the entire conversation re. WebID value prop.

Anonymity for instance, is achieved by multiple IDs. This also brings 
transitivity, owl:sameAs, and inference into the mix. The only trouble 
with those items is that they take use into some of the deeper echelons 
of RDF based Linked.

Note: Mac OS X also allows you to associate a Cert. with a specific data 
space (site) URL. Said binding would apply to browsers like Safari and 
Chrome that  leave Cert. based authentication to the OS (which is how I 
personally it should be done).




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

More information about the foaf-protocols mailing list