Handle User-Focused Client Constraining Access Control via the ACL about authorization-panel HOT 12 OPEN

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.

from authorization-panel.

@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

from authorization-panel.

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.

from authorization-panel.

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

from authorization-panel.

what is an "Authorization Agent"?

from authorization-panel.

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

from authorization-panel.

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

from authorization-panel.

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.

from authorization-panel.

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.

from authorization-panel.

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.

from authorization-panel.

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)

from authorization-panel.

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.

from authorization-panel.