Re: WebKey - was: WebID-protected WebID document

Thans for the reply. I think the protocol is quite clear as it is, but it
should avoid adding any extra lookups or requests, which would impact
performance negatively.

I saw the requirement for WebID document to be 'public'. But I think there
are 2 types of 'publicness' here that could be clarified.

Making the document public in ACL is easy, but it's not enough.

Because on the SSL level, the client must not authenticate with a (WebID)
certificate when requesting an internal WebID, otherwise it will get into a
loop.

Which has the implications that for internal requests: 1) 2 types of HTTPS
clients need to be available, one that sends a WebID certificate and one
that doesn't 2) the server (or at least the URI space of WebID documents)
has to 'want' a certificate and not 'need' it.

This was a concern for us because the system is doing a lot of internal
loopback requests. Did I manage to explain it? :)
On Wed, 21 Jun 2017 at 17.58, Henry Story <henry.story@bblfish.net> wrote:

>
> On 21 Jun 2017, at 10:55, Martynas Jusevičius <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
>
> 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
>
>
>