Re: mitigating Webid (+ TLS') single point of failure

Melvin, you forget that you could also use .onion or .garlic urls if you really don't want to rely on DNS.

As for the rest I think it is interesting. But it seems like a lot of work, which will require
working on a logic of trust, and much more. Perhaps a Phd thesis?


On 11 Jun 2013, at 18:30, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> The WebID + TLS flow has one single point of failure, and that is that you have to trust the profile page.  If the profile page is somehow compromised, or the victim of a MITM attack your whole authentication process could be compromised.
> 
> Now some people say you can add trust by adding an SSL certificate, or in the future, perhaps DNSSEC.  However, this can be unsatisfactory, because A) it's costly, B) you are just shifting the single point of failure around.  Other projects have pushed back against using WebID for this reason.
> 
> A more effective technique might be to distribute trust across the whole web. 
> 
> When the TLS handshake takes part, the sever can be mathematically sure, that the public key it receives is authentic.
> 
> The *standard* flow is to add a forward follow-your-nose lookup from the certificate to your profile page.  But what if we, as a community, were to distribute the trust across many many servers, using the read write web.  
> 
> Instead of a FORWARD (follow your nose) lookup, you can do a REVERSE lookup on the public key, using the di: (digest) URI scheme.  A neat feature of the di: spec is that it also has a /.well-known/di directory where you can put digests and and get back a document.  
> 
> It may be fairly simple to set up a single directory that allows users to go in and update their info on your server.   You may even charge a small fee for it.
> 
> In this way a server does not have to rely on a single point of failure as the relationship between a key and a user will be distributed in many places.  In this way you can perform extra checks as required to verify the authenticity of a login, as needed...
> 
> 

Social Web Architect
http://bblfish.net/