Re: Delegated WebID paper

On 2014-05-07 00:10, Andrei Sambra wrote:
> First of all, I'm glad that we're having these exchanges and that people are waking up. The list has been really quiet over the past few months.

I didn't really seek this explosion of messages, I only wanted to highlight that
there's another and currently *much bigger* user-base of X.509 client certificates
who have turned to proprietary solutions since HTTPS Client Cert Authentication
from their perspective has too many limitation, most of them not related to UI.

I saw (still see) an obvious reason to collaborate on this since if you look a bit
deeper into the "auth" part, Paypal and Google will eclipse the promoters of the
"distributed web" since U2F really only supports the former in a useful manner.

Anyway, I skimmed your paper and found it interesting!

I have a minor comment.  Using TLS server-certificates for client-authentication will
probably require some special measures since the EKU "Client Authentication" is missing.
Is there a workaround? Yes, and that is rather using signed requests which also is what
I proposed for the standard WebID use-case and is also the method used by U2F (and OAuth?).

Anders

> 
> Here is some food for thought:
> 
> I've been thinking about a possible fix for the UI and client certs and so I hacked together a WebID-TLS delegated access/authentication proxy! Henry and I have published a paper [1] on it some time ago. Please take a look at it before commenting/asking questions.
> 
> Basically, instead of directly fetching resources from the client, you send all your requests to the proxy (to which you can authenticate using whatever mechanism you want). This is Step (1).
> 
> (2) The proxy then fetches the initial resource while authenticating itself using WebID-TLS (this is trivial) and also sending a special header called "On-Behalf-Of" that contains your WebID (the URI which identifies you). This header is used to indicate that the request is done by an agent on behalf of a user. Your profile must also indicate that you delegate the agent by adding  a triple which states that "<Your WebID> acl:delegatee <Proxy's WebID>". 
> 
> (3) The server hosting the resource authenticates the proxy and dereferences the WebID in the "On-Behalf-Of" header to check for the "acl:delegatee" relation. The server can then decide whether you trust the proxy or not (because you've added that relation), and then if everything is ok it will apply the ACL policies specific to your WebID.
> 
> (4) Finally, the proxy returns the resource it just received from the server back to you.
> 
> Here is a quick example of how you intercept requests using jQuery
> 
> jQuery.ajaxPrefilter(function(options) {
>   options.url = "https://rww.io/auth-proxy?uri=" + encodeURIComponent(options.url);
> });
> 
> The proxy can also be optimized to cache the resources, which would _greately_ increase the responsiveness of your requests. The biggest advantage this mechanism provides is that you (as a user) don't even need to care about client certificates. The proxy server does all the heavy lifting. However, you _really_ have to trust the proxy server.
> 
> 
> -- Andrei
> 
> [1] http://hal.archives-ouvertes.fr/docs/00/74/53/55/PDF/paper.pdf
> 
>

Received on Wednesday, 7 May 2014 05:29:49 UTC