Re: WebKey - was: WebID-protected WebID document

Sorry, I should have been clearer.

The setup I was describing is where the server also includes a client and
is requesting its own (WebID-protected) resources, and is hosting the WebID
profiles themselves.

Say

GET http://localhost/some/doc
Accept: text/html

from a web browser may lead to

GET http://localhost/
Accept: text/turtle

from the internal client.

The loop issue happens when a request is authenticated by dereferencing the
WebID URI, but that leads to a new request which again has to be
authenticated the same way, and so on and on. Unless the WebID documents
are made public not only in the ACL but also SSL sense, as I described
previously.

On Wed, Jun 21, 2017 at 9:54 PM, Henry Story <henry.story@bblfish.net>
wrote:

>
> > On 21 Jun 2017, at 19:02, Martynas Jusevičius <martynas@atomgraph.com>
> wrote:
> >
> > 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.
>
> You mean the server must not authenticate....
> I am not sure what you mean by "an internal WebID"
>
> >
> > 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.
>
> Section 4.2.4 does have some text on WANT vs NEED
> https://www.w3.org/2005/Incubator/webid/spec/tls/#requesting-the-client-
> certificate
> [[
> As much as possible it is important for the server to request the client
> certificate in WANT mode, not in NEED mode. If the request is made in NEED
> mode then connections will be broken off if the client does not send a
> certificate. This will break the connection at the application protocol
> layer, and so will lead to a very bad user experience. The server should
> therefore avoid doing this unless it can be confident that the client has a
> certificate - which it may be because the client advertised that in some
> other way to the server.
> ]]
>
> >
> > This was a concern for us because the system is doing a lot of internal
> loopback requests. Did I manage to explain it? :)
>
> You need to explain what you mean by internal WebID request and internal
> loopback request
>
> > 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
> >
>
>