bblfish
commented
3 years ago I agree with @elf-pavlik, and I think I expressed my support for that in the meetings since the beginning of the month. Now that we have track 315: for the creator metadata, and a potential answer the access control rule needed, we can just write out the request/response exchange.
I guess that having to make two requests to ACLs is going to be costly. So ideally we'd like to have just one. If consistency is the problem, it is true that one could(/should?) require the guard to make consistency checks to the ACL before writing them out.
Is the question to solve now the following:
what is the use case where having a wac:Delete access mode to a resource would be problematic, assuming that right is specified in the resource's ACR itself?
Is it a use case where one wants to give the user control over the resource, which would allow them to set the wac:Delete mode, but the user should only be able to DELETE it if they have wac:Write access to the container? Can one work that out in more detail?
elf-pavlik
It is welcome that the authorization-panel wants to propose that the protocol needs to define the access modes in a universal way. It has been on my agenda for a while to propose it, as it is important to ease the tensions between the authorization systems.
I have read Authorization UCR and I note that its access modes definitions are incompatible with WAC, and so with Solid as currently defined. I take it as a requirement that the Protocol must be compatible with WAC as defined, and I believe my this thinking does that, as well as satisfies the panel's requirements. I propose a structure where certain access modes grant rights that are a strict subset of others.
However, for the purpose of the Protocol spec, I suggest that we define in terms of operations rather than access modes, and then attach access modes to operations. It is understood that the requirements in the following are on the server, in case I don't include that in every sentence. Thus, there isn't a one-to-one correspondence between the work of this panel and my suggestion, mine is more constrained by Solid as currently defined.
So, here are some ideas for discussion:
Read operation
The server MUST return a representation of the target resource as a response to a read operation.
State changes in existing resources
The server MUST NOT change the state of any resource as a result of a read operation.
Implementation
A request MUST use
GET,HEADorOPTIONSfor read operations, as defined.Access Mode
To execute a read operation, an agent is required to be authorized with a Read access mode. Read is a top level access mode, mutually exclusive with Write and Control.
List operation
State changes in existing resources
A list operation MUST NOT change the state of any resource.
Implementation
To confirm the existence of a resource, the server MUST respond with a
204.A server implementing this access mode MUST also implement the Prefer Request Header of LDP. A client requests a list operation by using the
includeparameter with a value ofhttp://www.w3.org/ns/ldp#PreferContainment. A server MUST respond with403if the header is not present and the requesting agent has List permission.Issue: The
Expectheader is possibly closer to what we want here, and it could be defined analogous to thePreferheader.Access Mode
List (aka File Scan) is an access mode that is a subset of Read that allows only list operations to be executed.
Write operation
A Write operation MAY make any change to the target resource. The server MAY perform validation and filtering steps on the request. As a result of a write operation, the server will change the parent container by adding or removing containment.
State changes in existing resources
A write operation may change the state of the target resource or its parent container.
Implementation
PUT,PATCH,POSTas defined.Access Mode
To execute a write operation, an agent is required to be authorized with a Write access mode on the target resource. If the write operation results in a change of state of the parent container, the agent is also required to be authorized to perform the resulting operation on that container. Write is a top level access mode, mutually exclusive with Read and Control.
Modify operation
State changes in existing resources
A modify operation MUST NOT change the state of any other resource than the target resource, except when a new resource is created, then the server will change the parent container by adding or removing containment.
Implementation
Mostly as defined.
Access Mode
To execute a modify operation, an agent is required to be authorized with a Modify or Write access mode on the target resource. If the modify operation results in a change of state of the parent container, the agent is also required to be authorized to perform the resulting operation on that container. Modify is an access mode that is a subset of Write. It is mutually exclusive with Delete.
Append operation
State changes in existing resources
An append operation MUST NOT change the state of any other resource than the target resource, except when a new resource is created, then the server will change the parent container adding containment.
Implementation
The special characteristics of append operations aren't well defined currently, it would need to be improved in a separate effort.
Access Mode
To execute an append operation, an agent is required to be authorized with a Append, Modify or Write access mode on the target resource. If the modify operation results in a change of state of the parent container, the agent is also required to be authorized to perform the resulting operation on that container. Append is an access mode that is a subset of Modify.
Create operation
State changes in existing resources
Changes the state of the parent container.
Implementation
As defined
It is an error to attempt a create operation on an existing non-container resource (in practice, this would currently not happen, since the server can't in such cases distinguish a create operation from a modify operation).
Access Mode
To execute a create operation, an agent is required to be authorized with a Create, Append, Modify or Write access mode on target resource if it is an existing container, or on the parent container if it does not. Append is an access mode that is a subset of Modify.
Delete operation
A delete operation removes the representation of the target resource.
State changes in existing resources
A delete operation changes the state of the target resource and the parent container.
Implementation
As defined.
Access Mode
To execute a delete operation, an agent is required to be authorized with a Delete or Write access mode on the target resource. Since the delete operation results in a change of state of the parent container, the agent is also required to be authorized to perform the resulting operation on that container, in this case, it needs a Write or Modify access mode on the parent container. Delete is an access mode that is a subset of Write. It is mutually exclusive with Modify.
Control operation
A control operation includes read, create, modify or delete the resource containing a representation of authorizations.
State changes in existing resources
A control operation only changes the state of the target resource.
Implementation
As defined.
Access Mode
To execute a control operation, an agent is required to be authorized with a Control access mode on the target resource. Control is a top level access mode, mutually exclusive with Write and Read.
Read Permissions operation
A read permissions operation can read the resource containing a representation of authorizations.
State changes in existing resources
A read permissions operation MUST NOT change the state of any resource.
Implementation
GETon a access control resource.Access Mode
To execute a read permissions operation, an agent is required to be authorized with a ReadPermissions access mode. ReadPermissions is an access mode that is a subset of Control.
Some considerations
Minimal requirement on a Solid Server
We need to determine which access modes MUST be supported by a Solid server. WAC's set of Read, Write, Append and Control seems like a good starting point, with the rest defined to be MAY.
Break compatibility by disallowing append to create resources?
From the principle of least privilege, it seems, at least intuitively, to be attractive that a modify operation should not include the create operation, and so more a hierarchy like this:
It is however clear that the append operation is a subset of the modify operation and so that would break the current definition of the Append access mode. Moreover, if we keep WACs current access modes as the minimum, it would mean that you'd need Write to create a resource, which is also not good seen from the principle of least privilege.
Linking and propagation of access control
Control may need to change the state of many other resources depending on the outcome of current work regarding propagation and/or linking of resources to their access controls. This is a breaking change relative to current Solid. In general, I'm a bit divided on what we should do about the impact of state changes done as a side effect by the server.
Definition of terms
It seems to me that "Access Control Resource" should be a generic term for any such resource, including WAC's ACL resources and ACP's ACRs. Thus, the latter will have to give that up for the greater good. :-)
Audit logs, etc
At some point, I'd like to see an auxiliary resource that is an audit log, in which case all operations may append to the audit log, and so all methods would be changing the state of that resource as a side effect. This would then need to be added.
No corresponding WritePermission
Offhand, I couldn't see a use case for a corresponding WritePermission or AppendPermission. It seems that you would always need to read the authorizations to be able to change them meaningfully, and therefore, I didn't put in an analog. I also acknowledge the interesting idea in https://github.com/solid/specification/issues/303 .
Operations discussions
There have been similar discussions in the protocol, notably a series of issues https://github.com/solid/specification/issues/126 , https://github.com/solid/specification/issues/149 , https://github.com/solid/specification/issues/165 and https://github.com/solid/specification/issues/118
I have also felt that the protocol needs an editorial overhaul that should make it easier for others to reference it. My thinking is that an emphasis on various operations should do that.