WebKey - was: WebID-protected WebID document

> On 21 Jun 2017, at 10:55, Martynas Jusevičius <martynas@atomgraph.com <mailto:martynas@atomgraph.com>> wrote:
> 
> Hi,
> 
> I've started implementing the WebID Authentication Protocol.
> 
> I extract the WebID URIs from certificates and try to look them up and verify -- so far so good.
> 
> But, since the WebID URIs are local to my system, and the whole system is protected by WebID, it means that WebID URIs themselves are protected by WebID. This leads the Guard/Verifier into an eternal loopback.
> 
> WebID 1.0 says both that WebID documents should be public and served over HTTPS.
> 
> The only way to achieve that that I can see is for the Verifier to dereference WebID document over HTTPS but without sending a client certificate. Which also means that the server's clientAuth has to be configured as 'want' rather than 'need' (and naturally the ACL has to be configured to allow public access to WebID).
> 
> Are my assumptions correct? Maybe this should be clarified in the protocol spec?

yes, the WebID Profile document should be public to avoid the problem - as specified in the spec.

One could place the key in another document, and have a URL point from the WebID profile to the other key. 

<#me> cert:key <key#>

But then we would also need to change some other things to the protocol. Firstly of course because the 
Subject Alternative Name in the X509 certificate contains the WebID, not a Key URL. And there would
be no way for the client to find out the key URL unless that is also added to the certificate - which would
be a not insubstantial piece of work to standardization work.

On the other hand it would make sense to work on a new spec to incorporate HTTP-Signature to WebID.
I implemented this in Scala-JS (Scala compiling to JS) 1 and a half years ago and left some notes 
on my experience and pointers to the code here
  https://github.com/solid/solid-spec/issues/52 <https://github.com/solid/solid-spec/issues/52>

This protocol works by giving the key a URL, and it works at the HTTP level, which is good.
But one would need to work out the details of how one can tie it to a WebID, to allow social
networking information to be shared. ( I think I wrote some thoughts down on that topic there)

Henry

> 
> 
> Martynas
> atomgraph.com <http://atomgraph.com/>