Re: Loops or ACL logic? - was: WebKey - was: WebID-protected WebID document

I think I have solved the loop issue by creating a second type of HTTP
client for the internal requests that does not send a client certificate.

ACL logic is an issue here if the WebID documents are not made public, but
I would expect it to result in Verifier error if it receives 401 or 403
when dereferencing the WebID. That is a different situation, not leading to
a loop.

But if Verifier dereferences WebID successfully, it becomes an SSL issue
that does lead to a loop for local WebIDs. Consider this flow:

#1 Verifier: authenticating incoming request to https://localhost/some/doc

#2 Verifier: retrieved WebID from certificate:
https://localhost/agents/me#this (from web browser)

#3 Verifier/Client: dereferencing WebID URI https://localhost/agents/me

#4 Verifier: authenticating incoming request to https://localhost/agents/me

#5 Verifier: retrieved WebID from certificate:
https://localhost/agents/secretary#this (internal client)

#6 Verifier/Client: dereferencing WebID URI
https://localhost/agents/secretary

#7 Verifier: authenticating incoming request to
https://localhost/agents/secretary

#8 Verifier: retrieved WebID from certificate:
https://localhost/agents/secretary#this (internal client)

That's where it goes wrong, because steps 5-7 will just repeat themselves
non-stop, or until the HTTP client runs out of connections. The ACL level
is not even reached at this point.

Maybe this is a corner case or an obvious one, but I just want to reiterate
my key point: internal clients doing local requests *should not* send a
WebID certificate when dereferencing WebID documents themselves.


On Thu, Jun 22, 2017 at 7:36 PM, Henry Story <henry.story@bblfish.net>
wrote:

>
> On 21 Jun 2017, at 23:33, Jonas Smedegaard <jonas@jones.dk> wrote:
>
> Hi Martynas,
>
> Quoting Martynas Jusevičius (2017-06-21 21:37:24)
>
> 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.
>
>
> I believe WebID protocol does not require that access to reading the
> WebID URL be private.
>
> If you choose to restrict read access to the WebID to only people who
> themselves identy using WebID, then it is on you to ensure to not create
> a loop, e.g. when reading your own WebID.
>
>
> Yes. So we did resolve our loop problem by requiring WebID Profiles to be
> public.
>
> But it is an interesting question to consider the problem of loops in
> general in Linked
> Data with Access Control. I suppose the first thing would be to try to
> specify the
> problem in a general enough that helps locate the place the problem arises.
>
> In rww-play I don't think I have this problem because the server can
> access all local resources
> without authentication, and so also the WebID Profiles (that may be a
> problem, but I have not
> thought of an attack vector yet).
>
> But I suppose you are thinking of a resource A served by server S that
> requires authentication
> by Group G, one group G member M tries to authenticate but that requires S
> to access M's
> Profile. That profile is access controlled so S can't verify and so denies
> access....
>
> Don't we just always arrive at access denials in case the server can't
> access the right information?
> Perhaps it would be helpful if the server could explain why access is
> denied.
>
> So this is more of an issue of the logic of access control btw, rather
> than authentication.
>
> Henry
>
>
>
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 <+45%2040%2084%2031%2036>  Website:
> http://dr.jones.dk/
>
> [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
>
>