[foaf-protocols] WebID talk at W3C - WebId+Flash
info at csarven.ca
Wed Aug 25 04:18:28 CEST 2010
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
More information about the foaf-protocols