Comments (18)
In the RDF representation of resource
y
, policy<#p1>
gives Read, Write and Control access over resourcex
(hence allowing editing of resourcey
itself as well).
I really don't like acl:Control
access mode. If one wants to give someone read access to ACR that would require adding acl:ControlRead
or something like that. I think using modes like Read
or Write
on ACR as well is very elegant in current version of ACP.
If you have acp:resource owl:inverseOf acp:accessControlResource
(let's forget any possible renaming for now), to have ACR have their own ACR one could use acp:accessControlResource
as link relation in HTTP header. (forgetting rel="acl" option for now). If one would use that and make ACR referencing itself as its own ACR, which would be similar to current approach of using acp:access
. Than we would have ACR linking to two different resources with acp:resource
. This would not allow setting separate policies on ACR and the other resource.
Alternative would be removing acp:resource
and don't even bother defining inverse for acp:accessControlResource
, one can always swap subject and object in the statement. Having that, we can define property with domain acp:AccessControl
named something like acp:policiesApplyTo
which would have any resource (including ACR) as range. This way we could have more than one resource linking to the same ACR and each Access Control would apply to one specific resource. This would preserve use of plain Read
, Write
access modes on ACRs.
from authorization-panel.
I like the simplification.
from authorization-panel.
After rethinking the problem I think we don't actually need to set specific policies on ACR itself. Just as the storage owner has implicit access to all the resources in the storage. We are going to have Authorization Server associated with each Resource Server (Storage). I think this associated Authorization Server can have similar implicit access to all ACRs.
In that case, Resource Owner sets policies using their Authorization Agent which results in the generation of Data Grants. Later the Authorization Server associated with Storage (RS) based on those Data Grants can set ACRs on the storage. I think it is not needed or even desired for any party other than AS to modify ACRs. Given all that I see no need to granular access control over ACRs themselves, implicit (as not expressed via ACRs) access for AS associated with RS seems sufficient.
from authorization-panel.
https://solid.github.io/authorization-panel/acp-specification/#access-control-resource
acp:resource
The ACP resource predicate links an ACP Access control resource to the resource over which it mandates access.acp:resource
has a range ofrdfs:Resource
and a domain ofacp:AccessControlResource
. An ACP Access control resource only ever mandates access over one resource and inversely a resource only ever has one ACP Access control resource mandating access over it. The one-to-one cardinality ofacp:resource
is denoted by it being anowl:FunctionalProperty
&owl:InverseFunctionalProperty
. Theacp:resource
predicate is the inverse ofacp:accessControlResource
.
Could you provide an example of ACR that includes policies over the resource, which ACR is auxiliary of, and policies over itself? Especially what would be referenced with acp:resource
.
from authorization-panel.
@elf-pavlik I think you're pointing out an interesting ambiguity/potential inconsistency. The acp:resource
predicate should probably as per being the inverse of acp:accessControlResource
be called acp:isAccessControlResourceFor
.
I think such inverse properties could hold for each of the ACP elements, that is: acp:isAccessControlFor
; acp:isPolicyFor
and acp:isMatcherFor
...
To respond more directly to your question:
- Let resource
x
be linked to resourcey
via a Link rel="acl" header - Resource
y
is therefore the Access Control Resource for resourcex
- Let resource
y
contains the following graph:<> acp:accessControl <#ac1> . <#ac1> acp:policy <#p1> . <#p1> acp:allow acl:Read, acl:Write, acl:Control .
- In the RDF representation of resource
y
, policy<#p1>
gives Read, Write and Control access over resourcex
(hence allowing editing of resourcey
itself as well).
from authorization-panel.
I am fine with removing acp:access
.
I am acp:apply
to acp:policy
. Doing so will break all existing clients and servers, and for what reason?
from authorization-panel.
If the acp:access
predicate is removed, there is no reason to have an inconsistent ontology. And the cognitive cost if that ontology is to be used and adopted widely which is what we're aiming for will be on the whole much higher than having this fixed now.
The schema allowing us to have:
R1 --acp:accessControlResource--> ACR1 --acp:accessControl--> AC1 --acp:policy--> P1
And inverse:
P1 --acp:isPolicyFor--> AC1 --acp:isAccessControlFor--> ACR1 --acp:isAccessControlResourceFor--> R1
Is much cleaner/intuitive/consistent/easy to describe and understand.
I do get your point about existing clients and servers, but there will be no moment in the future where such change will be even remotely possible or acceptable. I am very willing to make the effort right now for the sake of consistency and coherence.
from authorization-panel.
If the acl:ControlRead
mode is actually something that is required in Solid, it should be discussed and added.
I think we need to have a crystal clear map of which modes entail which operations in the Solid Protocol. And that is not ACP specific.
Now, when it comes to ACP, there is no reason for ACP to have two ways of determining access to resources documented within the specification.
So if we want to have ACRs on ACRs in Solid, we should have that properly discussed and there is nothing in the ACP data model that technically stops you from writing ex:acr1 acp:accessControlResource ex:acr2 .
. So there is really no reason whatsoever to have two predicates to link Access Controls to policies.
Having that, we can define property with domain
acp:AccessControl
named something likeacp:policiesApplyTo
which would have any resource (including ACR) as range.
The range is an inference property, so it would not have "any" in range. I don't know where you're going really with such a predicate. What you're describing is: ex:AC1 acp:policiesApplyTo ex:ACR1 .
which doesn't make sense. It also hints towards the fact that the current domain model is indeed misleading and ambiguous.
The chain is:
resource -> access control resource -> access control -> policy -> matcher
Note that access control resources, access controls, policies and matchers are resources (maybe the name access control resource is also confusing and access control list would be better and less inducing of the wrong idea that "resource" stands for a document). All of the nodes in an ACP authorization graph could be document or non-document resources, as per Cool URIs; it is not up to ACP to determine that.
from authorization-panel.
As I understand, the change you propose would not allow using common Read
, Write
modes on ACRs and would require dedicated modes like ControlRead
, 'Control(Write)` to set policies on ACRs?
resource -> access control resource -> access control -> policy -> matcher
That means that in ACR polices can be set just on a single resource which links to that ACR.
So if we want to have ACRs on ACRs in Solid, we should have that properly discussed and there is nothing in the ACP data model that technically stops you from writing
ex:acr1 acp:accessControlResource ex:acr2 .
It doesn't seem that ACR can reference itself to include policies on itself
ex:res1 acp:accessControlResource ex:acr1 .
ex:acr1 acp:accessControlResource ex:acr1 .
With above it would not be possible to set different policies on res1
and acr1
from authorization-panel.
What you are highlighting here is not meant to be valid because one of the restrictions of ACP which I am not propsing to remove here is that one access control resource has one resource. Therefore in the graph you propose:
ex:res1 acp:accessControlResource ex:acr1 .
ex:acr1 acp:accessControlResource ex:acr1 .
The RDFS Resources ex:res1
and ex:acr1
would be inferred to be the same.
However, there is nothing, even in the current situation, making the following graph problematic:
ex:res1 acp:accessControlResource ex:acr1 .
ex:acr1 acp:accessControlResource ex:acr2 .
If we did remove owl:InverseFunctionalProperty
from the acp:accessControlResource
property, a self referencing Access Control Resource would become sound and that might actually be a good idea because it is a simple level of expressivity we might not want to miss out on.
So in any case, there is nothing really preventing from expressing the second graph which would allow using acl:Read
and acl:Write
modes on an ACR as of today (to be clear, I am not advocating adopting such a solution in the Solid ecosystem, doing so would require time, evaluation, implementation feedback). Once again, I think that it is a Solid problem, not an ACP problem:
It is not up to ACP to mandate that permissions over an Access Control Resource will be mandated by another Access Control Resource (ACR on ACR), by a specific access mode (the Solid compliant acl:Control) or by another mechanism.
ACP helps you define authorization graphs and match them against request descriptions to determine access modes granted. Solid or any other protocol deciding to implement and use ACP can use those interfaces: Feed context graph; get back an access grant graph.
Solid on the other hand defines the details of interacting with HTTP addressable resources. It is up to Solid to define the details of how authorization auxiliary resources are discovered and which access modes entail which Solid operations. If there is a requirement for ControlRead
, it should be brought up discussed and potentially added to the acl
ontology (it feels like that one might get through given enough implementation feedback which we currently lack). Both WAC and ACP could use this mode. No need to break compatibility (including with the WAC-Allow header which turns out quite useful from an app developer's perspective). If a requiremeent for ControlAppend
becomes obvious, it should be also discussed (I don't think that one is a good idea).
There are a number of discussions about which access modes are actually required by Solid and we should not bypass those:
- solid/web-access-control-spec#85
- #253
- solid/solid#120 (and solid/solid#61)
- #194
- solid/specification#210 (comment)
from authorization-panel.
If we did remove
owl:InverseFunctionalProperty
from theacp:accessControlResource
property, a self referencing Access Control Resource would become sound and that might actually be a good idea because it is a simple level of expressivity we might not want to miss out on.
Even if owl:InverseFunctionalProperty
gets removed, one will not be able to set different policies on the resource and different set of policies on ACR . acp:access
is a current way to apply specific policies to ACR, by removing it there will be no way to assign the regular policy to ACR, instead it would require a workaround like extra access modes when formulating policies that apply to the non ACR resource.
from authorization-panel.
I really don't like acl:Control access mode. If one wants to give someone read access to ACR that would require adding acl:ControlRead or something like that. I think using modes like Read or Write on ACR as well is very elegant in current version of ACP.
If the acl:ControlRead mode is actually something that is required in Solid, it should be discussed and added.
This is actually quite an important point, which we already bumped into on a number of projects. The ability for a data owner (or other high-control user) to grant another user partial control access is a huge desirable. So, while I agree with a lot of what @matthieubosquet points out (orthogonality of Solid and ACP, current vocabulary being confusing ...), we should take care that if a switch is made to a single predicate, it is accompanied by another way to achieve this. Constructs like acl:ControlRead
can do that, but then we gain clearer orthagonality on one issue by losing it in another.
from authorization-panel.
Constructs like
acl:ControlRead
can do that, but then we gain clearer orthagonality on one issue by losing it in another.
Could you expand on what mean by that woutermont?
from authorization-panel.
@matthieubosquet, after reading the panel minutes of yesterday, I feel like not everyone is aligned on the meaning of ControlRead
. To clarify: what is needed, is a way to state that someone can control the access rules for a specific access modes, and not others. Since this should be possible for every access mode, of which there can (by extension) be any number, this constitutes an orthogonal dimension to that of the modes themselves.
So, given, a resource R
, and it's Access Control Resource A
, we should be able to constrain:
-
access to read
R
(i.e.acl:Read
) -
access to write to
R
(i.e.acl:Write
) -
any number of other kinds of access to
R
(e.g. append, list, some yet unknown modes...) -
access to control read access to
R
(i.e. what I meant byacl:ControlRead
) -
access to control write access to
R
(e.g.acl:ControlWrite
) -
access to control any number of other kinds of access to
R
(Note that these are all different access control modes for R
, not A
; for example: setting acl:Read
for A
is not the same as setting acl:ControlRead
for R
.)
Given that the "control modes" will always run parallel to the "base access modes" (this is the orthogonality), it is semantically weird to have define them separately (e.g. acl:Read
and acl:ControlRead
); and that is what something like acp:access
+acl:Read
and acp:apply
+acl:Read
could capture nicely.
Long story short: I agree with your intuition about the design flaw (ACRs are just resources), but I would redefine acp:access
, instead of dropping it.
from authorization-panel.
@woutermont my proposal is not about the nature of the acl:Control
access mode or its potential specialisations, say acl:ControlRead
. In fact, it is irrelevant to what I am describing.
ACP is a data model that is here to describe the conditions of access to a resource. As I have described in another comment already, the acp:access
predicate is unnecessary even if you wanted to define access to an ACR and apply to it the modes acl:Read
and acl:Write
.
Let us have an example Solid resource ex:SolidResourceA
linked via the acl
header to an example auxiliary authorization resource ex:SolidAuxiliaryACPAuthorizationResourceB
. That auxiliary authorization resource's RDF representation could very well be the following graph:
ex:SolidResourceA acp:accessControlResource ex:SolidAuxiliaryACPAuthorizationResourceB .
ex:SolidAuxiliaryACPAuthorizationResourceB acp:accessControl ex:ac1 .
ex:ac1 acp:policy ex:p1 .
ex:p1
acp:allow acl:Read, acl:Write ;
acp:anyOf ex:resourceAdminMatcher .
ex:resourceAdminMatcher
acp:agent ex:bob, ex:alice .
# And also:
ex:SolidAuxiliaryACPAuthorizationResourceB acp:accessControlResource ex:acr1 .
ex:acr1 acp:accessControl ex:ac1 .
ACP would understand the above graph as controling access to both the resource and its auxiliary authz resource via the access control ac1
, policy p1
and matcher resourceAdminMatcher
. Hence it would grant the access modes acl:Read
and acl:Write
over both ex:SolidResourceA
and ex:SolidAuxiliaryACPAuthorizationResourceB
.
Whether the Solid Protocol accepts that the acl:Read
and acl:Write
modes can be granted over an auxiliary resource is a different debate.
The acp:access
predicate is a mistake. It really should not exist, there is not reason for it to. I am not talking "intuitively" about it, I realised this fact by implementing ACP multiple times, seeing how damaging to code implementation this bad modelling decision was and reasoning about the nature of the model.
from authorization-panel.
@matthieubosquet, this is one of those issues where we both agree on the observation, but will keep talking in circles about the conclusion. So, even though I believe it to be a lot more efficient to tackle them together, I'll continue my point in another issue. Apologies for the inconvenience!
from authorization-panel.
To clarify: what is needed, is a way to state that someone can control the access rules for a specific access modes, and not others.
I'm planning to submit soon my proposal for delegation, I believe this will provide a more elegant way of sharing access and only require the storage owner to update any ACR in the storage, more precisely their Authorization Server would do it on their behalf - solid/solid-oidc#18 (comment)
https://solid.github.io/authorization-panel/authorization-ucr/#uc-delegation-subset already mentioned that idea of acl:Control
can be considered naive, given that via impersonation one can effectively share access they have anyways.
TBC soon in dedicated issue
If we conclude that ACR of ex:SolidResourceA
has to include rules for its auxiliary resources (if they can have their own rules). It might be worth introducing separate predicate, for example:
ex:SolidResourceA acp:accessControlResource ex:SolidAuxiliaryACPAuthorizationResourceB .
ex:SolidAuxiliaryACPAuthorizationResourceB acp:accessControl ex:ac1 .
ex:SolidAuxiliaryACPAuthorizationResourceB acp:accessControlForAuxiliary ex:ac5 .
ex:ac1 acp:policy ex:p1 .
# ex:p1 details aren't relevant
ex:ac5 acp:auxiliraryRelation acp:accessControlResource.
ex:ac5 acp:policy ex:p5 .
ex:p5
acp:allow acl:Read, acl:Write ;
acp:anyOf ex:acrMatcher .
# ex:acrMatcher details aren't relevant
As we see this would allow Access Control to apply to auxiliary resource based on given relation. It would also allow use of regular access modes like Read
, Write
.
from authorization-panel.
If we conclude that ACR of ex:SolidResourceA has to include rules for its auxiliary resources (if they can have their own rules). It might be worth introducing separate predicate, for example:
@elf-pavlik I think we're not 100% aligned on the meaning of acp:accessControlResource
.
This predicate links a resource to the thing that mandates access over it. Therefore it is perfectly possible to have a graph such that:
ex:SolidResourceA acp:accessControlResource ex:SolidAuxiliaryAccessControlResourceA .
ex:SolidAuxiliaryDescriptionForResourceA acp:accessControlResource ex:AccessControlResourceB .
ex:SolidAuxiliaryAccessControlResourceA acp:accessControlResource ex:AccessControlResourceC .
This graph could further contain everything about ex:SolidAuxiliaryAccessControlResourceA
, ex:AccessControlResourceB
and ex:AccessControlResourceC
. This graph could be the representation of the Solid Access Control List auxiliary resource ex:SolidAuxiliaryAccessControlResourceA
.
There is no need to create a new predicate for Solid auxiliary resources (or every type or Solid auxiliary resources) because they are resources.
Access Control Resources and therefore Access Controls can already apply to Solid Auxiliary Resources with this simple data model.
Note that this point is exactly why I pondered the idea of having acp:AccessControlList
instead of acp:AccessControlResource
as a less confusing name, because the ACP ontology defines access to resources and it is orthogonal to Solid's definition of Solid Resources and Solid Auxiliary Resources. Furthermore, very practically/literally, an acp:AccessControlResource
is a list of access controls (member or not) and nothing else.
include rules for its auxiliary resources (if they can have their own rules).
Absolutely, we should clarify on the Solid Protocol level which access modes can be granted over Solid Auxiliary Resources as entailing operations on each type thereof AND whether those can be granted separately from the access modes granted over a Solid Resource.
I can imagine for example that it would be quite handy to have only a certain class of agents able to edit the description or shape of a resource. The acp:accessControlResource
predicate enables that already.
from authorization-panel.
Related Issues (20)
- Relationship between UCRs and Solid user-stories HOT 2
- 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
- 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
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.