mitigating Webid (+ TLS') single point of failure

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