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

[Kingsley Idehen]

  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.

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


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen