Clarify use of and requirement for acl:origin predicate #59

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.