[foaf-protocols] WebID talk at W3C - WebId+Flash
kidehen at openlinksw.com
Wed Aug 25 03:53:53 CEST 2010
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
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.
> What matters in the user experience demo is that a real certificate can
> be generated, it contains an appropriate subject alternative name, that
> certificate can be selected when logging in over TLS, and there is proof
> that the information from the certificate was passed through to the
> server and is displayed on the login page. The details of verifying the
> public key (while quite obviously required for real authentication) are
> all hidden from the view of the user. This proof shows that the JS/Flash
> solution can work the same way that any browser-only solution works.
Again, cool innovation.
But do try to imbibe the essence of the WebID protocol and the various
patterns we've established here across implementations.
A WebID implementation shouldn't feel strange to members of this
mailing, for instance.
BTW - I got into your system using my old demo id. That id was invalid
i.e., the Demo ID (just like Henry). I've since made a new one using
your system, but I couldn't use it anywhere. Again, that's quite alien
re. WebID implementation experience. Normally, we get a WebID and use it
against any platform.
> In any event, we have added the same RDF information that can be
> retrieved from a foaf.me Web ID to the URLs in the demonstration just to
> alleviate some of these concerns. The public key that is generated when
> a certificate is created is stored in the profile, along with the
> nickname selected on the certificate creation page. Adding more
> information/features is mostly trivial but *takes time*.
> These features and those that do fancy sparql queries on the server,
> etc., have already been proven to work with other Web ID
> implementations. The time required to make use of them could be greatly
> reduced by simply cutting and pasting some open source implementation of
> PHP's redland librdf bindings doing sparql queries on Web ID urls (etc.)
> into the server-side code of the demo. Unfortunately, we have only been
> able to find links showing that this stuff is functional on other Web ID
> implementations, not the actual source code along with written
> permission to use it in our demonstration. The C source code for Joe's
> apache mod that does Web ID authentication is available, but we were
> looking specifically for PHP code.
> Do the other Web ID demonstrations out there do their server-side Web ID
> authentication in PHP or are they all just using the same apache module?
I don't use PHP or Apache. Virtuoso has this functionality in-built. ODS
is built using Virtuoso. Of course anyone could build an ODS like
product using Virtuoso also. Note, you can surface all DBMS persisted
modules (nee. SQL Stored Procedures) for RESTful interaction via HTTP.
> Is there some open source PHP code we can grab and just drop into our
> demo? If not, it isn't difficult to do, but will take time and it will
> not affect the user experience. That doesn't mean it should *never* be
> done, it just means that it can wait.
> Again, adding such features to our demonstration have been considered
> low priority since they are functioning elsewhere and, most importantly,
> they do not have a significant affect on the simplest generic user
> experience of authentication via Web ID.
> I realize that one of the greatest strengths of Web ID is the ability to
> store your identity in a single location and share all sorts of
> customized data with any number of sites that support Web ID, however, I
> can't say that I've seen any really powerful, interactive, and guided
> demonstration of this yet at all.
I will certainly make some. I am just back from vacation and in the
midst of a major product release.
I'll try though.
Remember, WebID is Jedi tech, so its not as easy to nail a demo in one
shot. You need a series of demos to really guide new users.
> We all know it *works* (via induction)
> but most demonstrations have focused on what the user experience would
> be if they were to login using Web ID.
WebID demos are about eradicating the login as known by typical
end-users. Yes, the initial browser challenge can be confusing, but I
don't think this is as bad as you assume, really. Firefox isn't used by
most end-users. IE, Safari, and even Chrome, all offer acceptable UI for
Also remember, Browsers are on the downward curve re. Web user agents
going forward. Thus, we can assume today's reality is what will always
be re. dominant user agent type.
> Ours is really no different in
> that respect other than that it proves that JS/Flash can replace a
> browser UI. And, by virtue of that, it provides a more guided and
> in-page-interactive process for creating and using a Web ID to authenticate.
Its a cool innovation. It has value, without doubt. I am just concerned
about the assumption that is the central matter re. WebID value prop.
In my experience, demonstrating no username and password based
authentication when logging into OpenID compliant data spaces (nee.
sites) has done the trick very well. Adding mailto: and acct: URI
schemes to the same demos ups the ante significantly for WebID (IMHO).
>> $ curl -k -i -L http://webid.digitalbazaar.com/demo/ids/1944828261
>> HTTP/1.1 302 Found
>> Date: Tue, 24 Aug 2010 22:55:43 GMT
>> Server: Apache/2.2.16 (Debian)
>> Location: https://webid.digitalbazaar.com/demo/ids/1944828261
>> Vary: Accept-Encoding
>> Content-Length: 324
>> Content-Type: text/html; charset=iso-8859-1
>> HTTP/1.1 404 Not Found
>> Date: Tue, 24 Aug 2010 22:55:45 GMT
>> Server: Apache/2.2.16 (Debian)
>> Vary: Accept-Encoding
>> Content-Length: 307
>> Content-Type: text/html; charset=iso-8859-1
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <title>404 Not Found</title>
>> <h1>Not Found</h1>
>> <p>The requested URL /demo/ids/1944828261 was not found on this server.</p>
>> <address>Apache/2.2.16 (Debian) Server at webid.digitalbazaar.com Port 443</address>
>> On the other hand what is interesting is that it works on all browsers simultaneously. I am sure I only made the WebId+flash on Chrome, but all the other browsers (Netscape, Firefox, Opera) could recognised me when I went to the /manage/ url.
>> So I suppose the trick is that the information is place inside the flash local datastore, and that this data store is shared between all browsers on my machine .
>>> You use the WebID on:
>> That works. But how? It can't be using the WebId protocol that dereferences information from the WebID, since there is nothing at that URL. I suppose it just fetches the information from the local flash store or something?
>> What would be nice would be a UML diagram and some documentation detailing how this works.
>> On 24 Aug 2010, at 22:22, 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 slides.
>>>>> 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 workaround
>>> for browsers who have not yet refined their SSL client UI. WebID needs
>>> 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.
>>> Also agreed with Steph on decentralization !~ availability.
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols