Clarify use of and requirement for acl:origin predicate · Issue #59 · solid/specification · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
acoburn opened this issue Sep 20, 2019 · 4 comments
Closed

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

acoburn opened this issue Sep 20, 2019 · 4 comments
Assignees
@csarven
Labels
doc: Web Access Control topic: authorization
Milestone
~First Public Wor...

Comments

@acoburn
Copy link
Member

acoburn commented Sep 20, 2019

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.
@RubenVerborgh
Copy link
Contributor

The entire "app authorization" mechanism likely needs a rework. Tagging @jaxoncreed.

One possible suggestion is to indicate all possible agents (people, apps, autonomous clients, …) with a WebID. And then creating a mechanism to say that a certain WebID corresponds to an app with a specific origin.

@elf-pavlik
Copy link
Member

I think we should keep all authZ related issues in https://github.com/solid/authorization-and-access-control-panel , otherwise we risk having parallel conversations about the same issues.

@kjetilk
Copy link
Member

kjetilk commented Nov 27, 2019

Indeed, this is under discussion in the authz panel.

@Mitzi-Laszlo Mitzi-Laszlo modified the milestones: December 19th, February 19th Jan 14, 2020
@csarven csarven modified the milestones: February 19th, ~First Public Working Draft Jan 24, 2020
@csarven csarven assigned csarven and unassigned dmitrizagidulin May 17, 2021
@csarven
Copy link
Member

csarven commented Jul 2, 2021

Thanks for this issue and discussion. Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #acl-origin , #authorization-conformance , #web-origin-authorization . Please use https://github.com/solid/web-access-control-spec for future discussion.

trustedApp is not in the ED. If need be, I suggest a new issue focusing on that.

@csarven csarven closed this as completed Jul 2, 2021
@csarven csarven moved this to Done in Specification Sep 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@csarven csarven

Labels
doc: Web Access Control topic: authorization
Projects
Specification
Status: Done
Milestone
~First Public Working Draft
Development

No branches or pull requests
7 participants
@kjetilk @csarven @RubenVerborgh @elf-pavlik @dmitrizagidulin @acoburn @Mitzi-Laszlo