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

[Sarven Capadisli]

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