deprecate acl:Control, replace with ...

[bblfish]

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 :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 :Tim .

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

[janellelynette]

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 :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 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).

[janellelynette]

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