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

Reto Bachmann-Gmür me at farewellutopia.com
Wed Aug 25 09:05:58 CEST 2010


Hi Dave

After the last telco I asked you a few question on how WebId+Flash works,
still it's not quite clear to me how things work.

You said that after authenticating via js+flash the way for the server to
authenticate the requests would be identical to after providing a client
certificate via "normal" browser client-auth. I'm wondering about the
javascript used to tell the browser to use a certain certificate for future
interactions with the server, does this work only for the current connection
as long as it is kept alive? or also with other connections the browser (or
some ajax-code within the site) opens?

what is the recommended procedure if the client first requests isn't to an
html which can contain js but to resource which cannot (e.g. an image) but
requires authentication. Should the server send some redirection? Or answer
html+js instead of the image first? what response code should be used?

Cheers,
reto


On Wed, Aug 25, 2010 at 3:13 AM, Dave Longley <dlongley at digitalbazaar.com>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.
>
> 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
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100825/89cd5007/attachment-0001.htm 


More information about the foaf-protocols mailing list