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

Dave Longley dlongley at digitalbazaar.com
Wed Aug 25 04:57:48 CEST 2010

On 08/24/2010 09:53 PM, 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 think without it, it's an extremely tough sell. People want to know 
what the average experience of a user of the technology will be like -- 
so they can determine whether or not the technology has a chance of 
being adopted. It's understandable that the technology will evolve and 
get better over time, but it's a far stronger sell when there's 
something attractive, as far as user experience is concerned, to begin with.

Showing how the technology might look, coupled with explaining all of 
the fantastic things it can do in the future is a good approach. I think 
leaving either one of these things out could result in some very 
negative feedback. It's great that Web ID can bring so much to the table 
in the future, however, we've got to enable a process to get us there 
first. It isn't a single step.

> 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..

I'm using the term "login" more liberally than I think I originally put 
across. By "login" I mean identifying yourself to a website/service. 
There is going to need to be some user interaction to make this happen, 
whether that is a UI in your browser or a UI on a web page. We wouldn't 
want to force people to use a single Web ID for all of their 
interactions with various data spaces -- and we wouldn't want to assume 
we know which one they'd like to use without their input. They might 
even change their mind at a latter point in time or get a new Web ID 
provider. There has to be a user interface to allow people to select how 
they wish to identify themselves ... and that interface is what I'm 
referring to as "login."

There doesn't have to be a username or password (like traditional login) 
and you don't need to be asking someone all that often for their 
credentials (very rarely, in fact -- and much of it could be automated 
but it still requires *some* user input).

People who are interested in Web ID are going to want to know all about 
the problems it solves and new doors it opens. But they are also going 
to want to know the basics for how its used to authenticate them with a 
service and what their experience would be before they will necessarily 
have any interest in what the future may hold. Without any idea of how 
that experience will unfold ... there's no clear path to the future.

> 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.
> Kingsley
>> 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.
> Hmm.
> 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
> Cert. selection.
> 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.
> demonstration.
> 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
>>> <html><head>
>>> <title>404 Not Found</title>
>>> </head><body>
>>> <h1>Not Found</h1>
>>> <p>The requested URL /demo/ids/1944828261 was not found on this server.</p>
>>> <hr>
>>> <address>Apache/2.2.16 (Debian) Server at webid.digitalbazaar.com Port 443</address>
>>> </body></html>
>>> 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:
>>>> https://payswarm.com/webid-demo/
>>> 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.
>>> Henry
>>> 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
>>>> mention Javascript or Flash.
>>>> 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
>>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Dave Longley
Digital Bazaar, Inc.
Phone: 540-961-4469

More information about the foaf-protocols mailing list