[foaf-protocols] WebID talk at W3C - WebId+Flash
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
>>>> It tells me that my webid is
>>>> 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:
>>> 1. Certificate generation.
>>> 2. Certificate selection.
>>> 3. TLS Certificate authentication (presentation of a certificate within
>>> 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
>> 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
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).
More information about the foaf-protocols