-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying permission sets for auxiliary resource types #174
Comments
In the context of shape validation, it is suggested that Write access on the resource would allow an agent to modify the corresponding shape for that resource. If that is correct, then consider the case where an app is legitimately permitted to write to a resource. Consider also that the app wishes to write invalid data. There would be nothing preventing the app from first modifying the shape, writing the (previously invalid) data, and then restoring the shape to its earlier form, thereby sidestepping any validation rules that the shape intended to impose on clients. Or am I missing something in the expected interactions? |
@acoburn Indeed. I think a somewhat similar issue happens with access control, server-managed and configuration resources. These may be slightly outside the scope of this issue if we change our lens from local to global (side-)effects. I've created #175 to capture the general case, referred to what you've raised and mentioned the others. If that makes sense, should we carry this bit over there? |
@acoburn You're absolutely right. I wrestled with this on shape validation, and had originally written that control access would be required, putting it on the same level as an ACL. I still believe that the integrity of the validation should be as important as the integrity of the access control, but the system doesn't yet have a way to automatically impose shape validations by default, which would lead to many applications getting control access when they shouldn't. I believe that ultimately support for shape trees on the server would allow us to address this by providing the server with a template to apply, but in the meantime we'll have to decide how we want to handle. |
@acoburn very valid concern. |
The issue with only doing this is that the first writer of a given resource needs control access to set the validation in the first place. We'd end up giving control access to everyone/everything because most apps need to make data. @acoburn, @ericprud, @joshdcollins, and i discussed a middle ground where only write access on resource A is needed to set the initial shape validation on resource A. Once it is set, control permission is needed to modify that shape validation assigned to resource A. Someone with write access to resource A would have to delete resource A and then recreate it if they set that shape validation in error. Ultimately server-side support for shape trees would allow us to assign a shape tree to a resource or container. That provides the server with the information that it needs to set initial and/or subsequent shape constraints on its own. This would allow us to tighten shape validation up to control level access, let a trusted agent with control access prepare a given area (e.g. this container is for meeting instances), and allow applications to create instances of meetings that have all of the proper shape constraints validated and assigned by the server automatically without needing control access. This isn't ready to incorporate today, because we're only wrapping the first iteration of the spec, but it's also not so far away that I'm not comfortable with a rational short term approach like the one proposed in the first paragraph. |
As defined in #156, Auxiliary Resources of various types are associated with Solid resources through link relations. Furthermore:
Based on the authenticated agent (or lack of authentication), the server must know whether to advertise the auxiliary resource in a link header at all, and then whether to allow the client to access and/or manipulate it.
In the case of WAC, it is well-established that without control access on a given Solid resource, the WAC auxiliary resource will not be advertised, nor able to be accessed or manipulated. We must determine what the permission rules should be for other auxiliary resource types (or whether there should be any stipulated in the spec at all).
In #156, we introduce five auxiliary resource types. The following permission sets are proposed:
Web Access Control
To discover, read, create, or modify an ACL auxiliary resource, an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it.
Resource Description
To create or modify a Descriptive auxiliary resource, a given acl:agent MUST have acl:Write privileges per the ACL inheritance algorithm on the resource directly associated with it.
To discover or read a Descriptive auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it.
Shape Validation
To create or modify a Shape validation auxiliary resource, an acl:agent MUST have acl:Write privileges per the ACL inheritance algorithm on the resource directly associated with it.
To read a Shape validation auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it.
Server Managed
To read a Server Managed auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it. Modes of access beyond acl:Read MUST NOT be permitted on a Server Managed auxiliary resource.
Edit: Configuration type has been removed from the submission, and is being tracked at #178.
The text was updated successfully, but these errors were encountered: