The semantics of the acl:origin predicate could be more clearly defined in the ACL vocabulary and/or in the Solid Web Access Control specification.
First, the acl:origin mechanism was created to add security to Solid resources. The WAC spec document clearly states:
When an Origin header is present then BOTH the authenticated agent AND the origin MUST be allowed access
The intention is to add a layer of security to resources. However, it is trivial for a web application to circumvent this feature (by taking the bearer token, which it already has access to, and passing that to either a same-origin endpoint or one with wide open CORS rules and then sending that same bearer token via a back channel with an arbitrary Origin header added to the request to the target resource server).
This feature also has significant (negative) implications on being able to design an ACL cache, which is vitally important for any high-load, high-performance server implementation.
In this context (significant disadvantages and questionable advantages), it would be helpful to clarify whether supporting acl:origin is a requirement of all servers.
It would also be helpful to clarify how acl:origin is supposed to work in an ACL document. The examples show acl:origin being used in tandem with acl:trustedApp, but acl:trustedApp is not present in the ACL vocabulary.
From an implementation perspective, it is unclear how one is to understand acl:origin in the context of other acl:Authorization scopes: is the intention that some acl:Authorizations will apply to users (i.e. WebIDs) and others will separately apply to acl:origin values? Or would those predicates be unified in a single acl:Authorization scope?
It is possibly worth noting that the ACL vocabulary defines acl:origin rdfs:domain acl:Authorization.
The semantics of the
acl:originpredicate could be more clearly defined in the ACL vocabulary and/or in the Solid Web Access Control specification.First, the
acl:originmechanism was created to add security to Solid resources. The WAC spec document clearly states:The intention is to add a layer of security to resources. However, it is trivial for a web application to circumvent this feature (by taking the bearer token, which it already has access to, and passing that to either a same-origin endpoint or one with wide open CORS rules and then sending that same bearer token via a back channel with an arbitrary
Originheader added to the request to the target resource server).This feature also has significant (negative) implications on being able to design an ACL cache, which is vitally important for any high-load, high-performance server implementation.
In this context (significant disadvantages and questionable advantages), it would be helpful to clarify whether supporting
acl:originis a requirement of all servers.It would also be helpful to clarify how
acl:originis supposed to work in an ACL document. The examples showacl:originbeing used in tandem withacl:trustedApp, butacl:trustedAppis not present in the ACL vocabulary.From an implementation perspective, it is unclear how one is to understand
acl:originin the context of otheracl:Authorizationscopes: is the intention that someacl:Authorizations will apply to users (i.e. WebIDs) and others will separately apply toacl:originvalues? Or would those predicates be unified in a singleacl:Authorizationscope?It is possibly worth noting that the ACL vocabulary defines
acl:origin rdfs:domain acl:Authorization.