Open bblfish opened 3 years ago
This issue comes in 2 parts: 1) The problem with
:Control
2) What to replace it byThe problem with
Control
acl:Control
is a very different mode toacl:Read
andacl:Write
.<#Rule> a :Authorization; :accessTo <resource>; :mode ?m ; :agent :Tim .
When the mode
?m
is:Read
or:Write
the rule applies to the object of:accessTo
. When the mode is:Control
the rule applies to the resource linked to by the object of:accessTo
via aLink: <...>; rel="acl"
header.Those are two very different methods of finding out what the rule applies to, which makes code implementing this very messy. A client reasoner coming to such a rule with
:Control
mode has to keep in mind where it came from to know if that rule applies. At least that is what the definition tells us.acl:Control Allows access to a class of read and write operations on an ACL resource associated with a resource.
This is even clearer if we are dealing with an ACL document that contains other rules including a number of
:default
rules.<#RuleDefaultCtrl> a :Authorization; :default </>; :mode :Control; :agent :Tim .
Remember, it is quite possible for a document on the web (on another server even) to contain a link straight to an acl resource. Would a client now have to find a resource in the hierachy, with a link relation to the ACL to work out what those rights are?
Replace with ...
The last example tells us that
:Control
is nothing more than an acl of:Read
and:Write
on the document itself. That is the last Rule could have been written more clearly as<#RuleDefaultCtrl> a :Authorization; :accessTo <>; :mode :Read, :Write; :agent :Twiggy .
With this in place, access-control on the acl would work exactly like access to any other resource and the logic of the system would be simplified a lot, removing potential errors and confusion. As an implementer of client and server libraries it would help make client and server auth code a lot simpler.
Epistemological Twist
How does a Guard know that the ACL rule (e.g.
<#RuleDefaultCtrl>
above) is indeed authoritative regarding that resource? The answer has to be that the acl document must come with aLink: <>; rel="acl"
header stating that it is its own acl. Then we have a very simple algorithm: to find the acls of a document, find theacl
Link header: that is the one the server will use to establish rights to access. This is simple and clean and can work for every resource on the server.Conclusion
So really we need not replace
:Control
with anything. All we need is just to apply theacl
algorithm everywhere the same way (without:Control
).
This issue comes in 2 parts: 1) The problem with
:Control
2) What to replace it byThe problem with
Control
acl:Control
is a very different mode toacl:Read
andacl:Write
.<#Rule> a :Authorization; :accessTo <resource>; :mode ?m ; :agent :Tim .
When the mode
?m
is:Read
or:Write
the rule applies to the object of:accessTo
. When the mode is:Control
the rule applies to the resource linked to by the object of:accessTo
via aLink: <...>; rel="acl"
header.Those are two very different methods of finding out what the rule applies to, which makes code implementing this very messy. A client reasoner coming to such a rule with
:Control
mode has to keep in mind where it came from to know if that rule applies. At least that is what the definition tells us.acl:Control Allows access to a class of read and write operations on an ACL resource associated with a resource.
This is even clearer if we are dealing with an ACL document that contains other rules including a number of
:default
rules.<#RuleDefaultCtrl> a :Authorization; :default </>; :mode :Control; :agent : pookie .
Remember, it is quite possible for a document on the web (on another server even) to contain a link straight to an acl resource. Would a client now have to find a resource in the hierachy, with a link relation to the ACL to work out what those rights are?
Replace with ...
The last example tells us that
:Control
is nothing more than an acl of:Read
and:Write
on the document itself. That is the last Rule could have been written more clearly as<#RuleDefaultCtrl> a :Authorization; :accessTo <>; :mode :Read, :Write; :agent :janelle
With this in place, access-control on the acl would work exactly like access to any other resource and the logic of the system would be simplified a lot, removing potential errors and confusion. As an implementer of client and server libraries it would help make client and server auth code a lot simpler.
Epistemological Twist
How does a Guard know that the ACL rule (e.g.
<#RuleDefaultCtrl>
above) is indeed authoritative regarding that resource? The answer has to be that the acl document must come with aLink: <>; rel="acl"
header stating that it is its own acl. Then we have a very simple algorithm: to find the acls of a document, find theacl
Link header: that is the one the server will use to establish rights to access. This is simple and clean and can work for every resource on the server.Conclusion
So really we need not replace
:Control
with anything. All we need is just to apply theacl
algorithm everywhere the same way (without:Control
).
This issue comes in 2 parts: 1) The problem with
:Control
2) What to replace it byThe problem with
Control
acl:Control
is a very different mode toacl:Read
andacl:Write
.When the mode
?m
is:Read
or:Write
the rule applies to the object of:accessTo
. When the mode is:Control
the rule applies to the resource linked to by the object of:accessTo
via aLink: <...>; rel="acl"
header.Those are two very different methods of finding out what the rule applies to, which makes code implementing this very messy. A client reasoner coming to such a rule with
:Control
mode has to keep in mind where it came from to know if that rule applies. At least that is what the definition tells us.This is even clearer if we are dealing with an ACL document that contains other rules including a number of
:default
rules.Remember, it is quite possible for a document on the web (on another server even) to contain a link straight to an acl resource. Would a client now have to find a resource in the hierachy, with a link relation to the ACL to work out what those rights are?
Replace with ...
The last example tells us that
:Control
is nothing more than an acl of:Read
and:Write
on the document itself. That is the last Rule could have been written more clearly asWith this in place, access-control on the acl would work exactly like access to any other resource and the logic of the system would be simplified a lot, removing potential errors and confusion. As an implementer of client and server libraries it would help make client and server auth code a lot simpler.
Epistemological Twist
How does a Guard know that the ACL rule (e.g.
<#RuleDefaultCtrl>
above) is indeed authoritative regarding that resource? The answer has to be that the acl document must come with aLink: <>; rel="acl"
header stating that it is its own acl. Then we have a very simple algorithm: to find the acls of a document, find theacl
Link header: that is the one the server will use to establish rights to access. This is simple and clean and can work for every resource on the server.Conclusion
So really we need not replace
:Control
with anything. All we need is just to apply theacl
algorithm everywhere the same way (without:Control
).