If the client is a server-side application, it can easily set any origin it wants in the HTTP header. WAC has acl:origin used for access control; if it relies on an HTTP header, it can be very easily circumvented. The same applies to the trusted apps experiment if the server relies on the HTTP origin header.
An alternative relies on client identifiers; for example, Solid-OIDC sets an app claim in the issued ID Token. This doesn't work with dynamic client registration since client identifiers are ephemeral. ACP has acp:client matcher, and a similar proposal exists for WAC https://github.com/solid/web-access-control-spec/issues/81
michielbdejong
commented
2 weeks ago
Original issue from 2018 https://github.com/solid/web-access-control-spec/issues/34
TL;DR
If the client is a server-side application, it can easily set any origin it wants in the HTTP header. WAC has
acl:originused for access control; if it relies on an HTTP header, it can be very easily circumvented. The same applies to the trusted apps experiment if the server relies on the HTTP origin header.An alternative relies on client identifiers; for example, Solid-OIDC sets an
appclaim in the issued ID Token. This doesn't work with dynamic client registration since client identifiers are ephemeral. ACP hasacp:clientmatcher, and a similar proposal exists for WAC https://github.com/solid/web-access-control-spec/issues/81