Comments (12)
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 seemsacl:Authorization
andacl: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.
- 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
andacl: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
? theresource.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:
- Alice authorizes iSay to post on solid forum.
- Bob want's to test iSay and only gives it very limited capabilities which don't include posting to solid forum.
- 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.
Related Issues (20)
- Required Credentials Discovery HOT 6
- support Trig serialization of Access Control Resources
- define a 2nd relation for ACRs to go with "acl" HOT 1
- Ideas for access modes and corresponding operations in the Protocol HOT 53
- acp:CreatorAgent logic HOT 5
- place meeting minutes on "draft-minutes" branch HOT 3
- Process Point of Order in meeting 2021-09-29 HOT 15
- ACP Draft design flaw HOT 18
- Distinction between policies which can be enforced by technology and by law HOT 5
- Enforce a secure default for client restrictions HOT 5
- Consider ACP matcher for conditional by relationship
- Update authorization-ucr's editors HOT 5
- Specify that the modes available are calculated using the resolution algorithm.
- Remove acp:mode from Context properties HOT 2
- Cannot match a context that contains a client/issuer HOT 4
- ACP vocabulary base URI problems HOT 1
- Serve ACP vocabulary from its base URI
- Authorization focused meetings HOT 13
- Clarify and/or mitigate risks related to negation (acp:deny) HOT 2
- ACP acronym also used for: Authoritative Claims Provider (OIDC + VC)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from authorization-panel.