{"id":14156486,"url":"https://github.com/solid/web-access-control-spec","last_synced_at":"2026-01-28T10:33:07.276Z","repository":{"id":37251459,"uuid":"55252136","full_name":"solid/web-access-control-spec","owner":"solid","description":"Web Access Control (WAC)","archived":false,"fork":false,"pushed_at":"2025-03-15T23:15:11.000Z","size":1052,"stargazers_count":122,"open_issues_count":28,"forks_count":24,"subscribers_count":28,"default_branch":"main","last_synced_at":"2025-03-15T23:25:04.321Z","etag":null,"topics":["specification"],"latest_commit_sha":null,"homepage":"https://solid.github.io/web-access-control-spec/","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/solid.png","metadata":{"files":{"readme":"README-v0.5.0.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-04-01T18:02:56.000Z","updated_at":"2025-03-15T23:15:15.000Z","dependencies_parsed_at":"2024-01-14T04:57:30.217Z","dependency_job_id":"e479c27b-8d04-49d9-bf6a-a95c351024c1","html_url":"https://github.com/solid/web-access-control-spec","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/solid/web-access-control-spec","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solid%2Fweb-access-control-spec","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solid%2Fweb-access-control-spec/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solid%2Fweb-access-control-spec/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solid%2Fweb-access-control-spec/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/solid","download_url":"https://codeload.github.com/solid/web-access-control-spec/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solid%2Fweb-access-control-spec/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28844014,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-28T07:39:25.367Z","status":"ssl_error","status_checked_at":"2026-01-28T07:39:24.487Z","response_time":57,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["specification"],"created_at":"2024-08-17T08:05:31.233Z","updated_at":"2026-01-28T10:33:06.586Z","avatar_url":"https://github.com/solid.png","language":"HTML","readme":"# Web Access Control (WAC)\n[![](https://img.shields.io/badge/project-Solid-7C4DFF.svg?style=flat-square)](https://github.com/solid/solid)\n\nWeb Access Control (WAC) specification (as used by the Solid project). It\nis based on Tim Berners-Lee's May 2009 proposal, as originally captured, and\nsubsequently evolved by the community, at\n[Web Access Control Wiki](https://www.w3.org/wiki/WebAccessControl). This spec\nis a particular subset of the options and extensions described in the wiki.\n\nFor use with [LDP](https://www.w3.org/TR/ldp/) (and [LDP\nNext](https://www.w3.org/community/ldpnext/)) type systems, such as the\n[Solid](https://github.com/solid/solid) project (see also the parent\n[spec](https://github.com/solid/solid-spec)).\n\n**Current Spec version:** `v.0.5.0` (see [CHANGELOG.md](CHANGELOG.md))\n\n## Table of Contents\n\n1. [Overview](#overview)\n2. [Access Control List Resources](#access-control-list-resources)\n  * [Containers and Inherited ACLs](#containers-and-inherited-acls)\n  * [Individual Resource ACLs](#individual-resource-acls)\n  * [ACL Resource Location Discovery](#acl-resource-location-discovery)\n3. [ACL Inheritance Algorithm](#acl-inheritance-algorithm)\n4. [Representation Format](#representation-format)\n5. [Example WAC Document](#example-wac-document)\n6. [Describing Agents](#describing-agents)\n  * [Singular Agent](#singular-agent)\n  * [Groups](#groups-of-agents)\n  * [Public Access (all Agents)](#public-access-all-agents)\n  * [Anyone logged on (Authenticated Agents)](#authenticated-agents-anyone-logged-on)\n  * [Referring to Origins, i.e. Web Apps](#referring-to-origins-ie-web-apps)\n7. [Referring to Resources](#referring-to-resources)\n8. [Modes of Access](#modes-of-access)\n9. [Default (Inherited) Authorizations](#default-inherited-authorizations)\n10. [Not Supported by Design](#not-supported-by-design)\n\n## Overview\n\nWeb Access Control (WAC) is a decentralized cross-domain access control system.\nThe main concepts should be familiar to developers, as they are similar to\naccess control schemes used in many file systems. It's concerned with giving\naccess to agents (users, groups and more) to perform various kinds of operations\n(read, write, append, etc) on resources. WAC has several key features:\n\n1. The resources are identified by URLs, and can refer to any web documents or\n  resources.\n2. It is *declarative* -- access control policies live in regular web documents,\n  which can be exported/backed easily, using the same mechanism as you would\n  for backing up the rest of your data.\n3. Users and groups are also identified by URLs (specifically, by\n  [WebIDs](https://github.com/solid/solid-spec#identity))\n4. It is *cross-domain* -- all of its components, such as resources, agent\n  WebIDs, and even the documents containing the access control policies, can\n  potentially reside on separate domains. In other words, you can give access\n  to a resource on one site to users and groups hosted on another site.\n\n## Access Control List Resources\n\nIn a system that uses Web Access Control, each web resource has a set of\n*Authorization* statements describing:\n\n1. Who has access to that resource (that is, who the authorized *agents* are)\n2. What types (or *modes*) of access they have\n\nThese Authorizations are either explicitly set for an individual resource, or\n(more often) inherited from that resource's parent folder or container. In\neither case, the Authorization statements are placed into separate WAC\ndocuments called *Access Control List Resources* (or simply *ACLs*).\n\n### Containers and Inherited ACLs\n\nThe WAC system assumes that web documents are placed in hierarchical containers\nor folders. For convenience, users do not have to specify permissions on each\nindividual resource -- they can simply set default permissions on a container using a\n[`acl:default`](#default-inherited-authorizations) predicate and the exact container URI\nas the object, and have all\nof the resources in that container [inherit](#acl-inheritance-algorithm) those\npermissions.\n\n### Individual Resource ACLs\n\nFor fine-grained control, users can specify a set of permissions for each\nindividual resource (which overrides any permissions of its parent container).\nSee the [Example WAC Document](#example-wac-document) section to get an idea\nfor what that would look like.\n\n### ACL Resource Location Discovery\n\nGiven a URL for an individual resource or container, a client can discover the\nlocation of its corresponding ACL by performing a `HEAD` (or a `GET`) request\nand parsing the `rel=\"acl\"` link relation.\n\nExample request to discover the location of the ACL resource for a web document\nat `http://example.org/docs/file1` is given below:\n\n```http\nHEAD /docs/file1 HTTP/1.1\nHost: example.org\n\nHTTP/1.1 200 OK\nLink: \u003cfile1.acl\u003e; rel=\"acl\"\n```\n\nThe request to discover the location of a container's ACL resource looks\nsimilar:\n\n```http\nHEAD /docs/ HTTP/1.1\nHost: example.org\n\nHTTP/1.1 200 OK\nLink: \u003c.acl\u003e; rel=\"acl\"\n```\n\nNote that the `acl` link relation uses relative path URLs (the absolute URL of\nthe ACL resource in the above example would be `/docs/.acl`).\n\nClients MUST NOT assume that the location of an ACL resource can be\ndeterministically derived from a document's URL. For example, given a document\nwith a URL of `/docs/file1`, clients cannot rely on the assumption that an ACL\nresource exists at `/docs/file1.acl`, simply using `.acl` as a suffix. The\nactual naming convention for ACL resources can differ for each individual\nimplementation (or even for each individual server). If one server locates the\nACL resource by appending the suffix `.acl`, another server could place the ACL\nresources into a sub-container (locating it at `/docs/.acl/file1.acl` for the\nexample above).\n\n## ACL Schemas\n\n*This section is non-normative.* ( Issue: https://github.com/solid/specification/issues/169 )\n\nThe following schema excerpts use these namespace prefixes:\n``` turtle\nPREFIX    acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e\nPREFIX     dc:  \u003chttp://purl.org/dc/terms/\u003e\nPREFIX  vcard:  \u003chttp://www.w3.org/2006/vcard/ns#\u003e\nPREFIX    xsd:  \u003chttp://www.w3.org/2001/XMLSchema#\u003e\n```\n### Authorization Schema\n``` turtle\n\u003c#authShape\u003e {\n  a [acl:Authorization] ;\n  acl:accessTo IRI ;\n  acl:mode [acl:Read acl:Write acl:Control]+ ;\n  (  acl:agent IRI ;\n   | acl:agentGroup @\u003c#groupShape\u003e +\n  ) ;\n}\n```\n\n### Group Schema\n\n``` turtle\n\u003c#groupShape\u003e {\n  a [vcard:Group] ;\n  vcard:hasUID IRI /^urn:uuid:/ ;\n  dc:created xsd:dateTime ? ;\n  dc:modified xsd:dateTime ? ;\n  vcard:hasMember IRI + ;\n}\n```\n\n## ACL Inheritance Algorithm\n\nThe following algorithm is used by servers to determine which ACL resources\n(and hence which set of Authorization statements) apply to any given resource:\n\n1. Use the document's own ACL resource if it exists (in which case, stop here).\n2. Otherwise, look for authorizations to inherit from the ACL of the document's\n  container. If those are found, stop here.\n3. Failing that, check the container's *parent* container to see if *that* has\n  its own ACL file, and see if there are any permissions to inherit.\n4. Failing that, move up the container hierarchy until you find a container\n  with an existing ACL file, which has some permissions to inherit.\n5. The *root container* of a user's account MUST have an ACL resource specified.\n  (If all else fails, the search stops there.)\n\nIt is considered an anti-pattern for a *client* to perform those steps, however.\nA client may [discover](#acl-resource-location-discovery) and load a document's\nindividual resource (for example, for the purposes of editing its permissions).\nIf such a resource does not exist, a client SHOULD NOT search for, or interact\nwith, the inherited ACLs from an upstream container.\n\n### ACL Inheritance Algorithm Example\n\n*Note:* The server in the examples below is using the ACL naming convention of\nappending `.acl` to resource URLs, for simplicity. As mentioned in the section\non [ACL discovery](#acl-resource-location-discovery), clients should not use\nor assume any naming convention.\n\nA request (to read or write) has arrived for a document located at\n`/documents/papers/paper1`. The server does as follows:\n\n1. First, it checks for the existence of an individual corresponding ACL\n  resource. (That is, it checks if `paper1.acl` exists.) If this individual ACL\n  resource exists, the server uses the Authorization statements in that ACL. No\n  other statements apply.\n2. If no individual ACL exists, the server next checks to see if the\n  `/documents/papers/` container (in which the document resides) has its own\n  ACL resource (here, `/documents/papers/.acl`). If it finds that, the server\n  reads each authorization in the container's ACL, and if any of them contain an\n  `acl:default` predicate, the server will use them (as if they were\n  specified in `paper1.acl`). Again, if any such authorizations are found, the\n  process stops there and no other statements apply.\n3. If the document's container has no ACL resource of its own, the search\n  continues upstream, in the *parent* container. The server would check if\n  `/documents/.acl` exists, and then `/.acl`, until it finds some authorizations\n  that contain `acl:default`.\n4. Since the root container (here, `/`) MUST have its own ACL resource, the\n  server would use the authorizations there as a last resort.\n\nSee the [Default (Inherited) Authorizations](#default-inherited-authorizations)\nsection below for an example of what a container's ACL resource might look like.\n\n## Representation Format\n\nThe permissions in an ACL resource are stored in Linked Data format\n([Turtle](http://www.w3.org/TR/turtle/) by default, but also available in other\nserializations).\n\n*Note: A familiarity with Linked Data and\n[RDF Concepts](http://www.w3.org/TR/rdf11-concepts/) helps with understanding\nthe terminology used in this spec.*\n\nWAC uses the [`http://www.w3.org/ns/auth/acl`](http://www.w3.org/ns/auth/acl)\nontology for its terms. Through the rest of the spec, the prefix `acl:` is\nassumed to mean `@prefix acl: \u003chttp://www.w3.org/ns/auth/acl#\u003e .`\n\n## Example WAC Document\n\nBelow is an example ACL resource that specifies that Alice (as identified by her\nWebID `https://alice.databox.me/profile/card#me`) has full access (Read, Write\nand Control) to one of her web resources, located at\n`https://alice.databox.me/docs/file1`.\n\n```ttl\n# Contents of https://alice.databox.me/docs/file1.acl\n@prefix  acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e  .\n\n\u003c#authorization1\u003e\n    a             acl:Authorization;\n    acl:agent     \u003chttps://alice.databox.me/profile/card#me\u003e;  # Alice's WebID\n    acl:accessTo  \u003chttps://alice.databox.me/docs/file1\u003e;\n    acl:mode      acl:Read, \n                  acl:Write, \n                  acl:Control.\n```\n\n## Describing Agents\n\nIn WAC, we use the term *Agent* to identify *who* is allowed access to various\nresources. In general, it is assumed to mean \"someone or something that can\nbe referenced with a WebID\", which covers users, groups (as well as companies\nand organizations), and software agents such as applications or services.\n\n### Singular Agent\n\nAn authorization may list any number of individual agents (that are being given\naccess) by using the `acl:agent` predicate, and using their WebID URIs as\nobjects. The example WAC document in a previous section grants access to Alice,\nas denoted by her WebID URI, `https://alice.databox.me/profile/card#me`.\n\n### Groups of Agents\n\nTo give access to a group of agents, use the `acl:agentGroup` predicate.\nThe object of an `agentGroup` statement is an instance of `vcard:Group`.\nThe WebIDs of group members are listed in it, using the\n`vcard:hasMember` predicate. If a WebID is listed as member of that group,\nit is given access.\n\nExample ACL resource, `shared-file1.acl`, containing a group permission:\n\n```ttl\n# Contents of https://alice.databox.me/docs/shared-file1.acl\n@prefix  acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e.\n\n# Individual authorization - Alice has Read/Write/Control access\n\u003c#authorization1\u003e\n    a             acl:Authorization;\n    acl:accessTo  \u003chttps://alice.example.com/docs/shared-file1\u003e;\n    acl:mode      acl:Read,\n                  acl:Write, \n                  acl:Control;\n    acl:agent     \u003chttps://alice.example.com/profile/card#me\u003e.\n\n# Group authorization, giving Read/Write access to two groups, which are\n# specified in the 'work-groups' document.\n\u003c#authorization2\u003e\n    a               acl:Authorization;\n    acl:accessTo    \u003chttps://alice.example.com/docs/shared-file1\u003e;\n    acl:mode        acl:Read,\n                    acl:Write;\n    acl:agentGroup  \u003chttps://alice.example.com/work-groups#Accounting\u003e;\n    acl:agentGroup  \u003chttps://alice.example.com/work-groups#Management\u003e.\n```\n\nCorresponding `work-groups` Group Listing document:\n\n```ttl\n# Contents of https://alice.example.com/work-groups\n@prefix    acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e.\n@prefix     dc:  \u003chttp://purl.org/dc/terms/\u003e.\n@prefix  vcard:  \u003chttp://www.w3.org/2006/vcard/ns#\u003e.\n@prefix    xsd:  \u003chttp://www.w3.org/2001/XMLSchema#\u003e.\n\n\u003c#Accounting\u003e\n    a                vcard:Group;\n    vcard:hasUID     \u003curn:uuid:8831CBAD-1111-2222-8563-F0F4787E5398:ABGroup\u003e;\n    dc:created       \"2013-09-11T07:18:19Z\"^^xsd:dateTime;\n    dc:modified      \"2015-08-08T14:45:15Z\"^^xsd:dateTime;\n\n    # Accounting group members:\n    vcard:hasMember  \u003chttps://bob.example.com/profile/card#me\u003e;\n    vcard:hasMember  \u003chttps://candice.example.com/profile/card#me\u003e.\n\n\u003c#Management\u003e\n    a                vcard:Group;\n    vcard:hasUID     \u003curn:uuid:8831CBAD-3333-4444-8563-F0F4787E5398:ABGroup\u003e;\n\n    # Management group members:\n    vcard:hasMember  \u003chttps://deb.example.com/profile/card#me\u003e.\n```\n[[test against schema](https://tinyurl.com/whcrhlo)]\n\n#### Group Listings - Implementation Notes\n\nWhen implementing support for `acl:agentGroup` and Group Listings, keep in mind\nthe following issues:\n\n1. Group Listings are regular documents (potentially each with its own `.acl`).\n2. What authentication mechanism should the ACL checking engine use, when making\n  requests for Group Listing documents on other servers?\n3. Infinite request loops during ACL resolution become possible, if an `.acl`\n  points to a group listing on a different server.\n4. Therefore, for the moment, we suggest that all Group files which are used\n  for group ACLs are public.\n\nPossible future methods for a server to find out whether a given agent is a\nmember of a group are a matter for future research and possible addition here.\n\n### Public Access (All Agents)\n\nTo specify that you're giving a particular mode of access to *everyone*\n(for example, that your WebID Profile is public-readable), you can use\n`acl:agentClass foaf:Agent` to denote that you're giving access to the class\nof *all* agents (the general public). For example:\n\n```ttl\n@prefix   acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e.\n@prefix  foaf:  \u003chttp://xmlns.com/foaf/0.1/\u003e.\n\n\u003c#authorization2\u003e\n    a               acl:Authorization;\n    acl:agentClass  foaf:Agent;                               # everyone\n    acl:mode        acl:Read;                                 # has Read-only access\n    acl:accessTo    \u003chttps://alice.databox.me/profile/card\u003e.  # to the public profile\n```\n\n### Authenticated Agents (Anyone logged on)\n\nAuthenticated access is a bit like public access\nbut it is not anonymous.   Access is only given to people\nwho have logged on and provided a specific ID.\nThis allows the server to track the people who have used the resource.\n\nTo specify that you're giving a particular mode of access to anyone *logged on*\n(for example, that your collaborative page is open to anyone but you want to know who they are),\nyou can use\n`acl:agentClass acl:AuthenticatedAgent` to denote that you're giving access to the class\nof *all* authenticated agents. For example:\n\n```ttl\n@prefix   acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e.\n@prefix  foaf:  \u003chttp://xmlns.com/foaf/0.1/\u003e.\n\n\u003c#authorization2\u003e\n    a               acl:Authorization;\n    acl:agentClass  acl:AuthenticatedAgent;                   # everyone\n    acl:mode        acl:Read;                                 # has Read-only access\n    acl:accessTo    \u003chttps://alice.databox.me/profile/card\u003e.  # to the public profile\n```\n\nNote that this is a special case of `acl:agentClass` usage, since it doesn't\npoint to a Class Listing document that's meant to be de-referenced.\n\nAn application of this feature is to throw a resource open to all logged on users\nfor a specific amount of time, accumulate the list of those who access it within \nthat time as a group, and then later restrict access to that group, to prevent spam.\n\n### Referring to Origins, i.e. Web Apps\n\n\nWhen a compliant server receives a request from a web application running\nin a browser, the browser will send an extra warning HTTP header, the Origin header.\n\n```\nOrigin: https://scripts.example.com:8080\n```\n(For background, see also [Backgrounder on Same Origin Policy and CORS](https://solid.github.io/web-access-control-spec/Background))\nNote that the origin comprises the protocol and the DNS and port but none of the  path,\nand no trailing slash.\nAll scripts running on the same origin are assumed to be run by the same\nsocial entity, and so trusted to the same extent.\n\n*When an Origin header is present then BOTH the authenticated agent AND\nthe origin MUST be allowed access.*\n\nAs both the user and the web app get to read or write (etc) the data, then they must BOTH\nbe trusted.  This is the algorithm the server must go through.\n\n - If the requested mode is available to the public, then succeed `200 OK` with added CORS headers ACAO and ACAH. **\n - If the user is *not* logged on, then fail `401 Unauthenticated`.\n - If the authenticated user is *not* allowed access, AND the class AuthenticatedAgent is not allowed access, then fail `403 User Unauthorized`.\n - If the Origin header is not present, then succeed `200 OK`.\n - If the Origin is allowed by the ACL, then succeed `200 OK` with added CORS headers ACAO and ACAH.\n - (In future proposed) Look up the owner's webid(s) to check for trusted apps declared there, and if match, succeed `200 OK` with added CORS headers ACAO and ACAH.\n - Fail `403 Origin Unauthorized`.\n\nNote it is a really good idea to make it clear both in the text of the status message and in the body of\nthe message the difference between the user not being allowed and the web app they are using\nnot being trusted.\n\n** Possible future alternative:  Set ACAO header to `\"*\"` indicating that the document is public.  This will though block in the browser any access made using credentials.\n\n#### Adding trusted web apps.\n\n** NB: this feature was only added recently and is still considered experimental. It's likely to change in the near future. **\n\nThe authorization of trusted web app is a running battle between readers and writers on the web, and malevolent parties trying to break in to get unauthorized access.  The history or Cross-Site Scripting attacks and the introduction of the Same Origin Policy is not detailed here, The CORS specification in general prevents any web app from accessing any data from or associated with a different origin.  The web server can get around CORS. It is a pain to to do so, as it involves the server code echoing back the Origin header in the ACAO header, and also it must be done only when the web app in question actually is trustworthy.\n\nIn solid a maxim is, you have complete control of he data. Therefore it is up to the owner of the data, the publisher, the controller of the ACL, or more broadly the person running the solid server, to specify who gets access, be it people or apps.   However another maxim is that you can chose which app you use.  So of Alice publishes data, and Bob want to use his favorite app,  then how does that happen?  \n\n - A Web server MAY be configured such that a given list of origins is unconditionally trusted for incoming HTTP requests. The origin check is then bypassed for these domains, but all other access control mechanisms remain active.\n - A specific ACL can be made to allow a given app to access a given file or folder of files, using `acl:origin`.\n - Someone with `acl:Control` access to the resource could give in their profile a statement that they will allow users to use a given app.\n\n```\n \u003c#me\u003e acl:trustedApp [ acl:origin  \u003chttps://calendar.example.com\u003e;\n                        acl:mode    acl:Read, \n                                    acl:Append].\n \u003c#me\u003e acl:trustedApp [ acl:origin  \u003chttps://contacts.example.com\u003e;\n                        acl:mode    acl:Read, \n                                    acl:Write, \n                                    acl:Control].\n```\n\nWe define the owners of the resource as people given explicit Control access to it.\n(Possible future change: also anyone with Control access, even through a group, as the group can be used as a role)\n\nFor each owner x, the server looks up the (extended?) profile, and looks in it for a\ntriple of the form\n\n```\n?x  acl:trustedApp  ?y.\n```\nThe set of trust objects is the accumulated set of ?y found in this way.\n\nFor the app ?z to have access, for every mode of access ?m required\nthere must be some trust object ?y such that\n```\n?y  acl:origin  ?z;\n    acl:mode    ?m.\n```\nNote access to different modes may be given in the same or different trust objects.\n\n## Referring to Resources\n\nThe `acl:accessTo` predicate specifies *which resources* you're giving access\nto, using their exact URLs as the objects.\n\n### Referring to the ACL Resource Itself\n\nSince an ACL resource is a plain Web document in itself, what controls who\nhas access to *it*? While an ACL resource *could* in theory have its own\ncorresponding ACL document (for example, `file1.acl` controls access to `file1`,\nand `file1.acl.acl` could potentially control access to `file1.acl`), one\nquickly realizes that this recursion has to end somewhere.\n\nInstead, the [`acl:Control` access mode](#aclcontrol) is used (see below), to\nspecify who has access to alter (or even view) the ACL resource.\n\n## Modes of Access\n\nThe `acl:mode` predicate denotes a class of operations that the agents can\nperform on a resource.\n\n##### `acl:Read`\ngives access to a class of operations that can be described as \"Read\nAccess\". In a typical REST API (such as the one used by\n[Solid](https://github.com/solid/solid-spec#https-rest-api)), this includes\naccess to HTTP verbs `GET`, and `HEAD`. This also includes any kind of\nQUERY or SEARCH verbs, if supported.\n\n##### `acl:Write`\ngives access to a class of operations that can modify the resource. In a REST\nAPI context, this would include `PUT`, `POST`, `DELETE` and `PATCH`. This also\nincludes the ability to perform SPARQL queries that perform updates, if those\nare supported.\n\n##### `acl:Append`\ngives a more limited ability to write to a resource -- Append-Only. This\ngenerally includes the HTTP verb `POST`, although some implementations may\nalso extend this mode to cover non-overwriting `PUT`s, as well as the\n`INSERT`-only portion of SPARQL-based `PATCH`es. A typical example of Append\nmode usage would be a user's Inbox -- other agents can write (append)\nnotifications to the inbox, but cannot alter or read existing ones.\n\n##### `acl:Control`\nis a special-case access mode that gives an agent the ability to *view and\nmodify the ACL of a resource*. Note that it doesn't automatically imply that the\nagent has `acl:Read` or `acl:Write` access to the resource itself, just to its\ncorresponding ACL document. For example, a resource owner may disable their own\nWrite access (to prevent accidental over-writing of a resource by an app), but\nbe able to change their access levels at a later point (since they retain\n`acl:Control` access).\n\n## Default (Inherited) Authorizations\n\nAs previously mentioned, not every document needs its own individual ACL\nresource and its own authorizations. Instead, one can can create an\nAuthorization for a container (in the container's own ACL resource), and then\nuse the `acl:default` predicate to denote that any resource within that\ncontainer will *inherit* that authorization. To put it another way, if an\nAuthorization contains `acl:default`, it will be applied *by default* to\nany resource in that container.\n\nYou can override the default inherited authorization for any resource by\ncreating an individual ACL just for that resource.\n\nAn example ACL for a container would look something like:\n\n```ttl\n# Contents of https://alice.databox.me/docs/.acl\n@prefix  acl:  \u003chttp://www.w3.org/ns/auth/acl#\u003e.\n\n\u003c#authorization1\u003e\n    a                  acl:Authorization;\n\n    # These statements specify access rules for the /docs/ container itself:\n    acl:agent          \u003chttps://alice.databox.me/profile/card#me\u003e;\n    acl:accessTo       \u003chttps://alice.databox.me/docs/\u003e;\n    acl:mode           acl:Read, \n                       acl:Write, \n                       acl:Control;\n\n    # default says: this authorization (the statements above) \n    #   will also be inherited by any resource within that container \n    #   that doesn't have its own ACL.\n    acl:default  \u003chttps://alice.databox.me/docs/\u003e.\n```\n\n## See also\n\n[Background on CORS](https://solid.github.io/web-access-control-spec/Background)\n\n## Old discussion of access to group files\n\n##### Group Listings - Authentication of External Requests\n\n*This section is not normative*\n\nGroup Listings via `acl:agentGroup` links introduce the possibility of an ACL\nchecking engine having to make requests to other servers. Given that access to\nthose external group listings can be protected, the question immediately arises:\nBy what mechanism should the ACL checking engine authenticate its request to\nexternal servers?\n\nFor example: Alice sends a GET request to a resource on the server\n`https://a.com`. The ACL for that resource links to a group listing on an\nexternal server, `https://b.com`. In the process of resolving the ACL, `a.com`\nmust send a request to `b.com`, to get that group listing. Note that it's not\nAlice herself (or her application) that is sending that request, it's actually\n`a.com` sending it (as part of trying to resolve its own ACL). How should\n`a.com` authenticate itself? Does it have its own credentials, or does it have\na way to say that it's acting on behalf of Alice? Or both?\n\nThere are several implementation possibilities:\n\n**No authentication**. The ACL checking engine sends *un-authenticated* requests\nto external servers (to fetch group listings). This is the simplest method to\nimplement, but suffers from the limitation that those external group listings\nneed to be public-readable. THIS IS THE ONLY METHOD CURRENTLY IN USE\n\n**WebID-TLS Delegation**. If your implementation uses the WebID-TLS\nauthentication method, it also needs to implement the ability to delegate its\nrequests on behalf of the original user.\n(No, the original requester may not be allowed access -- you don't have to able to\naccess a group to be in it)\nFor a discussion of such a capability,\nsee the [Extending the WebID Protocol with Access\nDelegation](http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf) paper.\nOne thing to keep in mind is - if there are several hops (an ACL request chain\nacross more than one other domain), how does this change the delegation\nconfirmation algorithm? If the original server is explicitly authorized for\ndelegation by the user, what about the subsequent ones?\n\n**ID Tokens/Bearer Tokens**. If you're using a token-based authentication system\nsuch as OpenID Connect or OAuth2 Bearer Tokens, it will also need to implement\nthe ability to delegate its ACL requests on behalf of the original user. See\n[PoP/RFC7800](https://tools.ietf.org/html/rfc7800) and [Authorization Cross\nDomain Code](http://openid.bitbucket.org/draft-acdc-01.html) specs for relevant\nexamples.\n\n##### Infinite Request Loops in Group Listings\n\nSince Group Listings (which are linked to from ACL resources using\nthe `acl:agentGroup` predicate) reside in regular documents, those documents\nwill have their very own `.acl` resources that restrict which users (or groups)\nare allowed to access or change them. This fact, that `.acl`s point to Group\nListings, which can have `.acl`s of their own, which can potentially also point\nto Group Listings, and so on, introduces the potential for infinite loops\nduring ACL resolution.\n\nTake the following situation with two different servers:\n\n```\nhttps://a.com                     https://b.com\n-------------        GET          ---------------\ngroup-listA        \u003c------        group-listB.acl\n    |                                  ^     contains:\n    |                                  |     agentGroup \u003ca.com/group-ListA\u003e   \n    v                GET               |\ngroup-listA.acl    ------\u003e        group-listB\n  contains:\n  agentGroup \u003cb.com/group-listB\u003e\n```\n\nThe access to `group-listA` is controlled by `group-listA.acl`. So far so good.\nBut if `group-listA.acl` contains any `acl:agentGroup` references to *another*\ngroup listing (say, points to `group-listB`), one runs into potential danger.\nIn order to retrieve that other group listing, the ACL-checking engine on\n`https://b.com` will need to check the rules in `group-listB.acl`. And if\n`group-listB.acl` (by accident or malice) points back to `group-listA` a request\nwill be made to access `group-listA` on the original server `https://a.com`,\nwhich would start an infinite cycle.\n\nTo guard against these loops, implementers have several options:\n\n**A) Do not allow cross-domain Group Listing resolutions**.\nThe simplest to implement (but also the most limited) option is to disallow\ncross-domain Group Listings resolution requests. That is, the ACL-checking code\ncould detect `agentGroup` links pointing to external servers during ACL\nresolution time, and treat those uniformly (as errors, or as automatic \"access\ndenied\").\n\n**B) Treat Group Listings as special cases**.\nThis assumes that the server has the ability to parse or query the contents of a\nGroup Listing document *before* resolving ACL checks -- a design decision that\nsome implementations may find unworkable. If the ACL checking engine can inspect\nthe contents of a document and know that it's a Group Listing, it can put in\nvarious safeguards against loops. For example, it could validate ACLs when they\nare created, and disallow external Group Listing links, similar to option A\nabove. Note that even if you wanted to ensure that no `.acl`s are allowed for\nGroup Listings, and that all such documents would be public-readable, you would\nstill have to be able to tell Group Listings apart from other documents, which\nwould imply special-case treatment.\n\n**C) Create and pass along a tracking/state parameter**.\nFor each ACL check request beyond the original server, it would be possible to\ncreate a nonce-type tracking parameter and pass it along with each subsequent\nrequest. Servers would then be able to use this parameter to detect loops on\neach particular request chain. However, this is a spec-level solution (instead\nof an individual implementation level), since all implementations have to play\nalong for this to work. See issue\n[solid/solid#8](https://github.com/solid/solid/issues/8) for further\ndiscussion).\n\n**D) Ignore this issue and rely on timeouts.**\nIt's worth noting that if an infinite group ACL loop was created by mistake,\nthis will soon become apparent since requests for that resource will time out.\nIf the loop was created by malicious actors, this is comparable to a very\nsmall, low volume DDOS attack, which experienced server operators know how to\nguard against. In either case, the consequences are not disastrous.\n\n\n### Other ideas about specifying trusted apps\n\n - A reader can ask to use a given app, by publishing the fact that she trusts a given app.\n\n ```\n \u003c#me\u003e acl:trustsForUse [ acl:origin  \u003chttps://calendar.example.com\u003e;\n                          acl:mode    acl:Read, \n                                      acl:Append].\n \u003c#me\u003e acl:trustsForUse [ acl:origin  \u003chttps://contacts.example.com\u003e; \n                          acl:mode    acl:Read, \n                                      acl:Write, \n                                      acl:Control].\n ```\n\nA writer could have also more sophisticated requirements, such as that any app Alice\nwants to use must be signed by developer from a given list, and so on.\n\nTherefore, by pulling the profiles of the reader and/or the writer, and/or the Origin app itself,\nthe system can be adjusted to allow new apps to be added without bad things happening\n\n\n## Not Supported by Design\n\nThis section describes some features or acl-related terms that are not included\nin this spec by design.\n\n##### Resource Owners\nWAC has no formal notion of a resource owner, and no explicit Owner access mode.\nFor convenience/UI purposes, it may be assumed that Owners are agents that have\nRead, Write and Control permissions.\n\n##### acl:accessToClass\nThe predicate `acl:accessToClass` is not supported.\n\n##### Regular Expressions\nThe use of regular expressions in statements such as `acl:agentClass` is not\nsupported.\n","funding_links":[],"categories":["others"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolid%2Fweb-access-control-spec","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsolid%2Fweb-access-control-spec","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolid%2Fweb-access-control-spec/lists"}