Security implications of ACL resources on different servers

[csarven]

Rough text from auxiliary resource:

A given Solid resource MAY Link to auxiliary resources on a different server under a different authority, per the configuration of the Solid server on which that resource resides.

If that goes through...

This entails that an ACL resource can be on a different server.. and so raises security issues that should be addressed.

• Will agent(s) controlling a resource on server-A be authorized to request write operations on the ACL on server-B? Ditto the application.

• What should happen if/when remote ACL becomes inaccessible (for whatever reason for any period)?

• What should happen if/when remote ACL is compromised?

• Would the server need to be authenticated and authorized like any other agent in order to:

  • name the ACL URI on different server, and making sure that the ACL can be created/modified (because it needs to have a link relation from primary resource to the ACL)
  • delete the associated ACL on different server?

[justinwb]

See this comment on the pull request. TLDR; I think it's safe to remove this statement and do the inverse (which would resolve this issue). If we wanted to retain the flexibility in general, we could limit this specifically for ACLs. However, since we want to have default permission sets for auxiliary resources I think it's better to keep them on same server under the same authority.

[csarven]

Sharing this comment from @emmettownsend :

I suspect most of the auxiliary resources will need to be cached as they will be used at runtime by the server to make decisions on a per request basis. Therefore, if they are remote there needs to be a way to tell the server they have changed; otherwise the server will be using an out of date copy which will result in security holes.

Edit: To add to above, the server may also persist the rel=acl relation in the headers even after agents no longer having Control on the resource ie. the expectation being that only agents with Control can observe the relation.

[quattro004]

If the ultimate question to resolve this issue is "Is MUST NOT too strong?" I would agree with @csarven, no it is not too strong. IMO security related information should not be ambiguous.

Also, regarding the statement following that "An auxiliary resource that resides on a Solid server MUST adhere to the same interaction model used by other regular Solid resources, except where specified in the definition of that auxiliary resource type." I think that the exceptional portion of the statement is open ended.

[csarven]

Moving this to WAC repo. There are some related considerations about Groups in https://github.com/solid/web-access-control-spec/blob/main/README-v0.5.0.md#group-listings---authentication-of-external-requests that can be taken up at the same time.

[csarven]

Noting that the current WAC Editor's Draft allows servers to associate resources and ACL resources, and they can be on different origins. See #web-origin-authorization #uri-origin .