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

> 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  Website: http://dr.jones.dk/ <http://dr.jones.dk/>
> 
> [x] quote me freely  [ ] ask before reusing  [ ] keep private