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

This is very similar to the "authentication deadlock" described in this
paper (page 2), except that in this case S == R.

http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf

On Thu, Jun 22, 2017 at 7:39 PM, Martynas Jusevičius <martynas@atomgraph.com
> wrote:

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