note: this could also be used by ACP. It would allow ACP to have virtual ACRs for a resource that are not created until needed, with a fallback to a default further up the hierarchy.
Details
There is currently a problematic tension in WAC between two things the acl link can point to:
it can point to the effective acl so that </foo/bar/baz/x> could return a Link: </.acr>; rel="acl" header
it could point to a not-yet-existing ACR, that a client with control access could edit if it wanted to specifically change rules for that resource
Both of these have problems, even if combined:
With (1), we help clients wanting to discover which credentials to present, find the resource effective ACL in one jump. We also don't create unnecessary Access Control Resources. But there is no way for a secure control enabled client to then find the ACR most closely associated with a resource, if it wants to place specific rules there.
With (2), we have the problem described in https://github.com/solid/authorization-panel/pull/244 (see markup ready version) that a client trying to access </foo/bar/baz/x> could end up having to make 9 (2n+1, where n are the number of slashes and 1 is the extra file) HTTP requests before it can find the effective ACR at </.default.acr> if it follows the effective acl algorithm. On the other hand a client with control access, wanting to make changes to the ACR for that resource, would immediately find the </foo/bar/baz/x.acr> that it could edit.
one could have a Link header with two acl type link relations, one pointing to the closest and the other to the default one, this would be an improvement over the current situation, but would still cause a lot of confusion, with clients having potentially to make 2 requests to get the ACR, when 1 request would have sufficed.
The problem comes from there being two needs to discover an ACR:
A client wishing read access, needing to determine what access rights it has and what credentials it should present to gain access
A client with control access, needing to determine which resource it should edit.
It is very likely that most resources will receive hugely more requests - to speak american english - from clients interested in Read modes than for clients wishing to change the ACL. So that would indicate that acls should link to the effective ACR. On the other hand it is critical the clients with Control access be able to set ACLs for individual resources.
One way to solve this is to have another link relation type in addition to the "acl" one we currently have.
Call this relation type "control". Then we could have the following
This would allow servers to point clients to the active ACR, without having to create pretty much empty resources everywhere. Since it is likely that using default ACRs is more maintainable than having ACR's for every resource, this seems like a good pragmatic way to solve the dilemma.
Acceptance criteria
What actions are needed to resolve this issue? (checklist)
csarven
commented
3 years ago
On proposal
WAC, ACP
note: this could also be used by ACP. It would allow ACP to have virtual ACRs for a resource that are not created until needed, with a fallback to a default further up the hierarchy.
Details
There is currently a problematic tension in WAC between two things the
acllink can point to:</foo/bar/baz/x>could return aLink: </.acr>; rel="acl"headerBoth of these have problems, even if combined:
</foo/bar/baz/x>could end up having to make 9 (2n+1, where n are the number of slashes and 1 is the extra file) HTTP requests before it can find the effective ACR at</.default.acr>if it follows the effective acl algorithm. On the other hand a client with control access, wanting to make changes to the ACR for that resource, would immediately find the</foo/bar/baz/x.acr>that it could edit.The problem comes from there being two needs to discover an ACR:
It is very likely that most resources will receive hugely more requests - to speak american english - from clients interested in Read modes than for clients wishing to change the ACL. So that would indicate that acls should link to the effective ACR. On the other hand it is critical the clients with Control access be able to set ACLs for individual resources.
One way to solve this is to have another link relation type in addition to the "acl" one we currently have. Call this relation type "control". Then we could have the following
This would allow servers to point clients to the active ACR, without having to create pretty much empty resources everywhere. Since it is likely that using default ACRs is more maintainable than having ACR's for every resource, this seems like a good pragmatic way to solve the dilemma.
Acceptance criteria
What actions are needed to resolve this issue? (checklist)