Giter VIP home page Giter VIP logo

Comments (2)

csarven avatar csarven commented on July 28, 2024 1

I think we should consider the possibility of clients to suggest the URI of the ACL they want to assign to a resource when creating or updating the resource.

It makes it possible to create the ACL before or after creating the resource - depending on their level of comfort and tolerance.

Helps to address use cases requiring decentralised ACLs.

In the case where Link rel=acl isn't specified, the server can still assign one as per usual.

The LINK method can be optionally used by a client to establish the relationships in Link (eg. pertaining to rel=acl/meta). This is useful in and itself because the location of acl/meta doesn't need to be sticky. It should be mutable so that the reference can change without having to re-create the resource with a new reference.

Let's be careful to not lose sight of the target resource with URI/API tricks. Slashes in path segments is different - native to URI (RFC).

That leaves us with having either the client to be explicit that a resource is an ACL or server figuring it out. The options are not mutually exclusive:

  1. Client: Content-Type - there isn't a mediatype for ACL (only existing RDF formats). Perhaps profile=solid:ACL can be used?
  2. Client: Link rel=type solid:ACL - new reference.
  3. Server: Processing the payload and checking against a data shape.
  4. Server: URI Template for ACL resources.
  5. ..

Option 1 - New media type for ACL is probably nonsensical (given that it is already in RDF... subtyping is meh). profile seems attractive eg. Content-Type: text/turtle; profile="http://www.w3.org/ns/solid/terms#AccessControl" (alternative: use acl ns and add class). Meaningful?

Option 2 - specifies "payload's abstract semantic type".

Option 3 - server probably should process the ACL shape any way.

Option 4 - server expects only ACL resources at designated URIs.

I think the following can work..

POST /foo/bar/
201
Location: baz
Link: <http://example.org/foo/bar/baz.acl>; rel="acl"

PATCH /foo/bar/baz.acl
Link: <http://www.w3.org/ns/solid/terms#AccessControl>; rel="type"

LINK /foo/bar/baz
Link: <http://example.net/.acl>; rel="acl"

from web-access-control-spec.

acoburn avatar acoburn commented on July 28, 2024

@csarven one possible issue with this proposal is whether a client suggests an ACL location or whether a client assigns an ACL location to a resource. And also whether a server implementation is free to ignore that.

Here are some issues that emerge if a client is able to assign an arbitrary ACL to a resource.

  1. An ACL resource could be a regular resource. Does this mean that this "regular resource" now is accessible only by those with acl:Control privileges? What if that resource already has its own ACL resource?

  2. What if the designated ACL resource is a child of the resource in question (in terms of LDP hierarchy)? How does that intersect with DELETE operations?

  3. If an untrustworthy application can get a user to assign a remote ACL to a resource -- an ACL that the user does not control, then a series of potential "loss of control" scenarios become quite real.

  4. How does a server enforce ACL restrictions in the case that an assigned ACL is temporarily inaccessible? (i.e. on a remote server that is under a DDoS attack?)

  5. If a client assigns an arbitrary ACL (e.g. an ordinary LDP-RS within the same server), what makes that a legitimate ACL resource? The mere presence of ACL triples? What happens if a user with acl:Write access to that "acl resource" is able to remove those triples or otherwise render the ACL graph semantically meaningless? And what happens if ACL triples are added to an ordinary LDP-RS? Does that resource become an ACL resource?

I'm not against this feature, because it could be implemented in a way that these concerns are addressed. OTOH, I would be concerned if support for this was absolutely required, because it introduces some significant issues that a server implementation could easily fall into.

from web-access-control-spec.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.