WAC issues with who is responsible for what is published on a POD

1

Hello,

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

Hi Vivien, if you’re interested in influencing the access control specs, you might be interested in providing your input to the Authorization panel (see also how panels work). As I understand it, they’re currently focusing on a proposal for a new access control system called “Access Control Policies”.

Some background reading you might also be interested in is the list of use cases and requirements they’re trying to support.

3

Hello!

Thank you, I did not know about this. The fact that Bob can edit the resume and the recruiter can view it while Alice is asleep is not something I find desirable. Imagine if Bob makes a mistake. The fault would fall on Alice’s shoulders. In my opinion, Bob should edit a copy of Alice’s resume on his own POD, with only him having write access and him and Alice having read access, and both should use MySuperSynchronizer app to synchronize their versions. So, Alice has a chance to review Bob’s work before accepting it on her POD.

I will try to clarify my views and send them to the panel.

1 Like