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

Wed Aug 25 03:13:33 CEST 2010

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.

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.

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.

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.

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.

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

> $ 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">
> <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
CTO
Digital Bazaar, Inc.
Phone: 540-961-4469