deprecate acl:Control, replace with ... #94

Activity

1. bblfish

   added a commit that references this issue on Aug 4, 2021

   implement solid/web-access-control-spec#94

   ae32ffe
2. janellelynette commented on Sep 30, 2023

   

   janellelynette

   on Sep 30, 2023 · Hidden as duplicate

   show commentMore actions
3. janellelynette commented on Oct 15, 2023

   

   janellelynette

   on Oct 15, 2023

   Last edited by janellelynette

   More actions

   This issue comes in 2 parts:

   1. The problem with :Control
   2. What to replace it by

   The problem with Control

   acl:Control is a very different mode to acl:Read and acl: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 a Link: <...>; 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 a Link: <>; 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 the acl 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 the acl algorithm everywhere the same way (without :Control).