Handle User-Focused Client Constraining Access Control via the ACL

[jaxoncreed]

This proposal details handling User-Focused Client Constraining Access Control via the ACL. Under this proposal, a fifth access control mode, acl:Clients would be added in addition to the standard ones, acl:Read, acl:Write, acl:Append, and acl:Control.

If a user has acl:Clients access, they are able to change the clients that can access a certain resource. The information on what clients can access the resource are stored in another file (let's say resource.clients.acl).

For example, let's say you wanted to control access to resource.ttl, then you might have the following metadata files:

resource.ttl.acl

<#owner>
    a acl:Authorization;
    acl:agent <https://jackson.solid.community/profile/card#me>;
    acl:accessTo </resource.ttl>;
    acl:mode acl:Read, acl:Write, acl:Control, acl:Clients.

In this case, only I can control the clients that can access this resource.

resource.ttl.clients.acl

<#rule>
    a acl:ClientAuthorization;
    acl:agent <https://coolApp.com#i>;
    acl:accessTo </resource.ttl>;
    acl:mode acl:Read

In this case, only "CoolApp" can have read access to my resource.

But, let's say I wanted to let everyone decide the apps that can have access. I can just set the acl to say:

resource.ttl.acl

<#public>
    a acl:Authorization;
    acl:agentClass foaf:Agent;
    acl:accessTo </resource.ttl>;
    acl:mode acl:Read, acl:Clients.

If I am an app user, I would depend on my Authorization Agent to update the client acls for the app I'm using.

Positives

• Works in the already established ACL system so it's less confusing to understand
• Given we are going with the route of having an authorization agent, it works in that model
• Still functions under the same trust model as "Resource Server Enforcement" described here (https://github.com/solid/authorization-and-access-control-panel/issues/53)

Possible Drawbacks

• Offloads complexity to the Authorization Agent
• The app would need to communicate with the Authorization Agent instead of a server to request additional access. The mechanism for such communication has not yet been created.
• We may want to consider more granular access control like acl:ClientAppend and acl:ClientWrite so that you can allow public users to only add to the apps that can access a resource. This would add complexity to the ACL system.

[elf-pavlik]

We may want to consider more granular access control like acl:ClientAppend and acl:ClientWrite so that you can allow public users to only add to the apps that can access a resource. This would add complexity to the ACL system.

acl:ClientAppend wouldn't allow people to revoke authorizations. At the same time allowing everyone to make writes freely may lead to one user messing with authorizations granted to a client by another user.

In cases where user grants client global access based on shape(tree)s or tags or whatever, Authorization Agent would need to automate reflecting those authorizations in suggested clients acl resources that user has access to.

[ewingson]

Works in the already established ACL system so it's less confusing to understand

this mechanism looks in my layman' s eyes simple, yet powerful. now I can see how we benefit from configuration triples. although I may have missed the historical details, the pieces of authentication/authorization begin to form a picture. let's gather more pluses/minuses/questions.

• easy to constrain to only read mode e.g.
• fine granulated rights are possible ? the resource.ttl.clients.acl defines the client as agent, the questionable app, I think ?
• the Authorization Agent still needs to be implemented

sum: makes a reasonable impression

[zenomt]

what is an "Authorization Agent"?

[ewingson]

I don' t know exactly - to be honest - and where it' s coded, but I see it as that part of the logic, that actually decides whether a green lamp for access or a red one for deny

[elf-pavlik]

@jaxoncreed if we take Discussion Boards use case and https://forum.solidproject.org/u as example. We find as of today 1187 users participating in solid forum, even if only 20% of them self-hosts their clients we would have over 100 clients added to clients ACL. Have you considered possibility of client ACL including hundreds of entries?

I also haven't see your response to situation where multiple users use a client same client id, but they would want to have different constraints put on that client. I'll document somewhere this scenario but for now will just post it here:

1. Alice authorizes iSay to post on solid forum.
2. Bob want's to test iSay and only gives it very limited capabilities which don't include posting to solid forum.
3. iSay posts spam on solid forum on behalf of Bob due to Alice's authorization.

Now if iSay posted it on behalf of Alice, she could get blacklisted, or iSay could get blacklisted if solid forum admin can confirm that it was iSay client fault and not Alice spamming. iSay posting on behalf of Bob seems problematic since Bob's authorization didn't include posting to solid forum. Even if client authorizations stay available on RS we may want to have a way to scope them to a specific user who granted it.

[elf-pavlik]

I think this approach also introduces possibility of racing condition, where client tries to access resources before authorization agent finishes updating all client acls it keeps track of.

[elf-pavlik]

Another nuance which just came to my mind. Since Authorization Agent pro-actively adds authorized client to all client acl resources it knows about, it eagerly discloses to all the RSs hosting those client acls that user uses that client even if user haven't actually tried accessing any resource on that RS with that client.

[bblfish]

Interesting idea. acl:Client does not quite seem to fit as an acl:mode attribute. You seem to rather be wanting to specify more precisely the agent. Following on that thought, something along the following lines may work better:

<#owner>
    a acl:Authorization;
    acl:agent [ a Persona; 
           webid <https://jackson.solid.community/profile/card#me>;
           useragent <https://coolApp.com#i>;
      ];
    acl:accessTo </resource.ttl>;
    acl:mode acl:Read, acl:Write, acl:Control, acl:Clients.

Somehow the Persona would be defined as something that both is identified by both a webid and a useragent. That would of course need more thinking through.

[bblfish]

From today's Panel discussion:

If the acl gives Control to a client and it can edit in order to restrict access, then it would make sense to add a subclass of foaf:Agent, call if foaf:Persona, that would be a person using an agent. We can find such ideas already in the 1991 famous paper A Calculus for Access Control in Distributed Systems which has evolved a lot. You'll find the notion of SpeaksFor there, which seems similar to such a Persona. I would need to think about it more.

That is a very early and influential article. A later one that is more accessible is Logic in Access Control (Tutorial Notes)

[timbl]

Note there is a bot https://timblbot.inrupt.net/profile/card#me which already accesses things on behalf of a person.

@prefix : <#>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix pro: <./>.
@prefix n0: <http://xmlns.com/foaf/0.1/>.
@prefix schem: <http://schema.org/>.
@prefix prov: <https://www.w3.org/ns/prov#>.
@prefix n: <http://www.w3.org/2006/vcard/ns#>.
@prefix n1: <http://www.w3.org/ns/auth/acl#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix inbox: </inbox/>.
@prefix sp: <http://www.w3.org/ns/pim/space#>.
@prefix tim: </>.
@prefix c: <https://www.w3.org/People/Berners-Lee/card#>.

pro:card a n0:PersonalProfileDocument; n0:maker :me; n0:primaryTopic :me.

:me
    a
        schem:SoftwareApplication, n0:Agent,
        prov:SoftwareAgent;
    n:fn "TimBlBot";
    n:hasPhoto <image_0.svg>, <noun_bot_2318640.svg>;
    n:note "I am a bot, and I do simple things for Tim";
    n:role "Admin";
    n1:trustedApp
            [
                n1:mode n1:Append, n1:Control, n1:Read, n1:Write;
                n1:origin <http://example.org>
            ];
    ldp:inbox inbox:;
    sp:preferencesFile </settings/prefs.ttl>;
    sp:storage tim:;
    solid:account tim:;
    solid:privateTypeIndex </settings/privateTypeIndex.ttl>;
    solid:publicTypeIndex </settings/publicTypeIndex.ttl>;
    n0:name "TimBLBot".
c:i schem:owns :me.

If the bot at the person each publish the relationship then it is reasonable to assume it is true.

[timbl]

But going back to the original proposal, I fin the RDF modeling very strange.

• Putting ACL related dat a in a separate xxx.clients.acl file means you have to duplicate all the discovery -Semantically seems acl:Authorization and acl:ClientAuthorization seem not a good diostinction
• If you can't actually distinguish between me logging in any an app logging in, then what is the point of using a big extra complicated system for handling the apps?
• If you are using your extended authentication protocol which logs in at the same time a person and an app, then that is quite different to allowing an app access with its own id.

Maybe the use case and trust model and workflow are not obvious to me.

[zenomt]

@jaxoncreed

• Given we are going with the route of having an authorization agent, it works in that model

restating my unanswered question from may 13:

what is an "Authorization Agent"?

i'm -1 on the notion of a user's (authorization) agent modifying ACLs on random servers to give access to an app for that user because:

• it's not scalable
• for "all users can choose their apps" (which should always be the case), it means a user can allow an app for someone else, and that a user could remove app authorizations from resources for someone else too