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

Dave Longley dlongley at digitalbazaar.com
Wed Aug 25 16:52:32 CEST 2010


On 08/25/2010 03:05 AM, Reto Bachmann-Gmür wrote:
> 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.

What I meant by that was that the Web ID protocol isn't any different 
for authenticating a request from the JS/Flash than it is for 
authenticating one from a different TLS client.

The JS/Flash implements TLS. It provides the server with the client-side 
certificate chosen by the user. The server does a TLS-layer check on the 
certificate and then dereferences the certificate's subject alternative 
name (the Web ID url) and obtains the RDF information at that location. 
It then checks the public key from the RDF with the public key received 
from the certificate to confirm that they are the same. Any information 
or negotiation over what data the server is allowed to receive from the 
Web ID url would either be done based on the Web ID used or yet another 
identity scheme (e.g. if the server were to use Web ID itself when 
communicating with the Web ID url).

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

In this regard, the JS/Flash has what may be seen as several advantages 
over the other options. A server can indicate to the JS/Flash whether or 
not it requires authentication for a particular resource on a 
per-resource basis. Otherwise, something a little similar to this, but 
not quite the same, can only be done with the new TLS renegotiation that 
isn't widely implemented yet. This means that the user doesn't need to 
be presented with a certificate selection box unless it's absolutely 
needed by the server. In addition to this, the client-certificate 
doesn't need to be sent and re-authenticated (via TLS+dereferencing) 
with every request. Authentication can be handled traditionally using 
cookies, once a Web ID has been used in the initial authentication. This 
saves the server from having to either open up a new https connection 
for every authentication, require the use of SSL sessions, or cache 
public keys from Web ID URLs.

That doesn't mean that the communication between JS/Flash can't include 
a certificate with every request. It just means that it doesn't have to 
happen that way. What certificate gets included by the JS/Flash is up to 
the user, and whether or not one gets included for every request can be 
an option provided by a user's Web ID provider (it's just software so it 
can be changed however is appropriate). The user's Web ID provider could 
also allow a user to customize what Web IDs they automatically send to a 
particular web site -- saving them the trouble of having to select the 
certificate when they visit. Their Web ID provider could allow multiple 
Web IDs to be used by a server -- all of this is fairly customizable 
since control over the UIs and user choice is exposed directly in 
software (JavaScript) as opposed to being inaccessible to Web ID 
provider developers (in the browser). Web ID providers can be quite 
customized.

So the shorter answer is that this can be made to work in whatever way 
seems best. If I were implementing a server I would personally want to 
avoid having to cache Web ID public keys if there was a solution that 
easily allowed me to avoid the trouble. That being said, maybe it isn't 
that much of an issue.

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

A redirection seems like the easiest solution. If the user has already 
associated a certificate with the website then the redirection and 
authentication would happen without any further interaction and the user 
could be immediately redirected back to the image. Think of it like TLS 
renegotiation at the HTTP layer -- except the software can direct 
whether or not the certificate is actually required and *only* send one 
in that case.

I'm hopeful that one day all of these sorts of options will become 
available in the browser, including perhaps the ability to customize 
your own interfaces into your personal identity management. Perhaps the 
usefulness of this in present form (JS/Flash) will help persuade browser 
manufacturers to consider the possibilities. But, at least in the 
meantime, we have something functional.

>
> Cheers,
> reto
>
>
> On Wed, Aug 25, 2010 at 3:13 AM, Dave Longley 
> <dlongley at digitalbazaar.com <mailto: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 <http://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 <http://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 <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100825/118ac22f/attachment-0001.htm 


More information about the foaf-protocols mailing list