I have a few issues with the WAC specification as I understand it. Maybe I have not understood everything correctly, so if you detect something false please tell me.
- the Control right is very troubling; if anyone else than the POD owner has control right over a resource then it can lock the owner away from the resource.
- letting people write to your POD is necessary, but I don’t think it is safe to give read access to the general public to something you are not directly responsible. I don’t think it is necessary either, because writers could use their own PODs.
- granting permission to apps (sandboxing) is not very effective, because an app can either read all the data, none, or the app needs to be mentioned in a selection of ACL files. The last solution is inefficient, because the permissions to apps is not correlated with the permissions to agents. It is also ineffective because it only works for you, as you can’t prevent your friends from using an app you don’t want.
- the groups should only be defined on the same POD as they are used. There can be an application to synchronize groups from other PODs, but it should require approbation by the POD owner.
- I don’t see a reason why two different people should be able to edit a document on someone else’s POD.
WAC explicitly refuses to recognize the concept of data ownership; I think it is a mistake. The resource owner is the agent that has editorial responsibility over the published data, and nothing should happen unless specific approval has been given. This means permissions should not change (either group listings or ACL content), and submitted data should not be public.
If I had to define a standard for access control, it would be this:
- the POD owner has all rights and is the only agent that can read or update ACLs.
- resources are either writable by the owner and readable by the public or specific or inherited agents or local groups, or writable by one specific agent and the owner and readable only by the owner.
- For the second kind of resources, the specific writer can be chosen when creating the resource by POST, by using a Link: header targetting the agent with the “writer” relation (we could mint an URI for that relation). That way, an application creating this resource does not need to view or edit the ACL directly.