Web Access Control
+Draft, 2021-07-11
+ +-
+
- This version +
- https://solidproject.org/TR/2021/wac-20210711 +
-
+
- Original resource +
- https://solidproject.org/TR/wac +
-
+
- Editor’s draft +
- https://solid.github.io/web-access-control-spec/ +
-
+
- TimeMap +
- https://solidproject.org/TR/wac.timemap +
-
+
- Created + +
-
+
- Published + +
-
+
- Modified + +
-
+
- Derived From +
- + + +
-
+
- Language +
- English +
-
+
- License +
- MIT License +
-
+
- Document Status +
- Draft +
-
+
- Resource State +
- Memento +
-
+
- In Reply To +
- Solid Origin +
-
+
- Policy +
-
+
-
+
- Rule +
- Offer +
- Unique Identifier +
- https://solidproject.org/TR/wac#document-policy-offer +
- Target +
- https://solidproject.org/TR/wac +
- Permission +
-
+
-
+
- Assigner +
- W3C Solid Community Group +
- Action +
-
+
-
+
- Aggregate +
- Archive +
- Concurrent Use +
- Derivative Works +
- Derive +
- Digitize +
- Display +
- Distribution +
- Index +
- Inform +
- Install +
- Notice +
- Present +
- Read +
- Reproduce +
- Reproduction +
- Stream +
- Synchronize +
- Text-to-speech +
- Transform +
- Translate +
+
+
+
Copyright © 2021 W3C Solid Community Group.
+ +Abstract
+Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model.
+Status of This Document
+This section describes the status of this document at the time of its publication.
+ +This document was published by the Solid Community Group as a Draft. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.
+ +Publication as a Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
+ +This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
+Introduction
+This section is non-normative.
+ +Unauthorized access or modification of Web resources could lead to unintended loss, damage or disclosure of data. To support read-write operations within the framework of HTTP, mechanisms for expressing and application of authorization conditions are needed to meet the social requirements of decentralised applications.
+ +Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model.
+ +The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such rules, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization can allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.
+ +Note: Specification Orthogonality
+This specification does not specify mechanisms for authentication or methods to verify assertions. It is assumed that systems using WAC have the ability to apply authentication and verification techniques when desired.
+The access control system can be enhanced by adding more inference or expressivity to express social constraints. See the Extensions section.
+ +This specification is for:
+ +-
+
- Resource server developers and security technicians who want to enable agents to obtain and control access to resources; +
- Application developers who want to implement a client to obtain and control access to resources. +
Terminology
+This section is non-normative.
+ +The WAC specification defines the following terms. These terms are referenced throughout this specification.
+ + + +-
+
- URI +
- A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986]. + +
- resource +
- A resource is the target of an HTTP request identified by a URI [RFC7231]. + +
- container resource +
- A container resource is a hierarchical collection of resources that contains other resources, including containers. + +
- root container +
- A root container is a container resource that is at the highest level of the collection hierarchy. + +
- ACL resource +
- An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations determining access to resources. + +
- Authorization +
- An Authorization is an abstract thing which is identified by a URI and whose properties are defined in an ACL resource, e.g., access modes granted to agents the ability to perform operations on resources. + +
- access mode +
- An access mode is a class of operations that can be performed on one or more resources. + +
- agent +
- An agent is a person, social entity or software identified by a URI, e.g., a WebID denotes an agent [WEBID]. + +
- agent group +
- An agent group is a group of persons or entities identified by a URI. + +
- agent class +
- An agent class is a class of persons or entities identified by a URI. + +
- origin +
- An origin indicates where an HTTP request originates from [RFC6454]. +
In addition to the terminology above, this specification also uses terminology from the [INFRA] specification. When INFRA terminology is used, such as string and boolean, it is linked directly to that specification.
+Namespaces
+| Prefix | +Namespace | +Description | +
|---|---|---|
rdf |
+ http://www.w3.org/1999/02/22-rdf-syntax-ns# | +[RDF-SCHEMA] | +
acl |
+ http://www.w3.org/ns/auth/acl# | +ACL ontology | +
foaf |
+ http://xmlns.com/foaf/0.1/ | +[FOAF] | +
vcard |
+ http://www.w3.org/2006/vcard/ns# | +[VCARD-RDF] | +
Conformance
+All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.
+ +The key words “MUST” and “MUST NOT” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
+HTTP Interactions
+This section is non-normative.
+ +Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, e.g., [SOLID-PROTOCOL], [LDP].
+ACL Resources
+This section describes ACL resource discovery and representation.
+ +ACL Resource Discovery
+When a server wants to enable applications to discover Authorizations associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation) and the ACL resource as link target [RFC8288].
ACL Resource Discovery is used towards determining the Effective ACL Resource of a resource.
+ +Issue: Link Relation Type
+The possibility of using URIs as relation types interchangeably or as alternate to the acl Link Relation type is under consideration, e.g., https://www.w3.org/ns/iana/link-relations/relation#acl or http://www.w3.org/ns/auth/acl#accessControl: issues/21.
Servers MUST NOT directly associate more than one ACL resource to a resource.
+ +Clients can discover the ACL resource associated with a resource by making an HTTP request on the target URL, and checking the HTTP Link header with the rel parameter.
Note: ACL Resource URI Security
+The URI of an ACL resource does not in itself pose a security threat ([RFC3986] security considerations). This specification does not constrain the discoverability of ACL resources.
+Note: URI Origin
+The resource and the associated ACL resource can be on different origins [RFC6454].
+Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.
+ +Source: issues/8, issues/62, issues/131, issues/176
+ACL Resource Representation
+An ACL resource is an RDF document [RDF11-CONCEPTS] that can hold any information, typically comprises an unordered set of Authorizations, any of which could permit an attempted access.
+ +Servers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].
Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT have a representation for the ACL resource that is associated with the resource.
+ +When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].
The root container MUST have an ACL resource with a representation.
+ + + +Source: issues/45
+HTTP Definitions
+wac-allow HTTP Header
+The syntax for the WAC-Allow header, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:
wac-allow = "WAC-Allow" ":" OWS #access-param OWS +access-param = permission-group OWS "=" OWS access-modes +permission-group = 1*ALPHA +access-modes = DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS DQUOTE +access-mode = "read" / "write" / "append" / "control"+ +
The WAC-Allow HTTP header’s field-value is a comma-separated list of access-params. access-param is a whitespace-separated list of access-modes granted to a permission-group.
Issue: WAC-Allow Access Modes
+Allow any access mode issues/82.
+This specification defines the following permission-groups:
-
+
user
+ - Permissions granted to the agent requesting the resource. +
public
+ - Permissions granted to the public. +
access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).
Client parsing algorithms for WAC-Allow header field-values MUST incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.
Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210
+acl Link Relation
+The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry [RFC8288].
+ +-
+
- Relation Name +
acl
+ - Description +
- The relationship
A acl Basserts that resource B provides access control description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
+ - Reference +
- This specification. +
- Notes +
- Consumers of ACL resources are encouraged to be aware of the source and chain of custody of the data. +
Extensions
+Extensions incorporate additional features beyond what is defined in this specification. Extensions MUST NOT contradict nor cause the non-conformance of functionality defined in the WAC specification.
+ + + +Access Mode Extensions
+An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.
Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.
+Permission Inheritance Extensions
+This section is non-normative.
+ + +Distinct Effective ACL Resource Extensions
+This section is non-normative.
+ +This specification describes the use of acl Link Relation for ACL Resource Discovery and the algorithm to determine the Effective ACL Resource of a resource. To enable clients to perform discovery faster, separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.
+Considerations
+This section details security, privacy, accessibility and internationalization considerations.
+ +Some of the normative references with this specification point to documents with a Living Standard or Draft status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.
+ +Security Considerations
+This section is non-normative.
+ +While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.
+ +Implementations are encouraged to follow the security considerations that are found in URI Generic Syntax, HTTP/1.1 Message Syntax and Routing and Semantics and Content.
+ +Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.
+ + + +Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g., by having audit trails, notification of changes, reasons for change, preserving provenance information.
+ +Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g., for purposes of provenance or accountability.
+Privacy Considerations
+This section is non-normative.
+ +The class of read and write operations require discrete access permissions:
+ +Access permission to append a new resource to a container resource is independent of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers can consider the risks when read access to the container is not granted to agents.
Access permission to update a resource is independent of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource might reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers can consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.
Accessibility Considerations
+This section is non-normative.
+Internationalization Considerations
+This section is non-normative.
+Security and Privacy Review
+This section is non-normative.
+ +These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].
+ +-
+
- What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? +
- There are no known security impacts of the features in this specification. + +
- Do features in your specification expose the minimum amount of information necessary to enable their intended uses? +
- Yes. + +
- How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them? +
- ACL resources can contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the
acl:Controlaccess mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information could be exposed.
+
+ - How do the features in your specification deal with sensitive information? +
- Same implications as personal information and personally-identifiable information in ACL resources and group resources. When including sensitive information, the sender can be aware that changes to a group resource’s Authorization can allow non-members or new members to view membership details. + +
- Do the features in your specification introduce new state for an origin that persists across browsing sessions? +
- No. + +
- Do the features in your specification expose information about the underlying platform to origins? +
- No. + +
- Does this specification allow an origin to send data to the underlying platform? +
- No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers might be able to redirect ACL resources, (e.g., the
https:URLs tofile:,data:, orblob:URLs), but no behaviour is defined by this specification.
+
+ - Do features in this specification allow an origin access to sensors on a user’s device +
- No. + +
- What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. +
- No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond normal CORS requests, so no extra mitigation is deemed necessary. + +
- Do features in this specification enable new script execution/loading mechanisms? +
- No. + +
- Do features in this specification allow an origin to access other devices? +
- No. + +
- Do features in this specification allow an origin some measure of control over a user agent’s native UI? +
- No. + +
- What temporary identifiers do the features in this specification create or expose to the web? +
- None. + +
- How does this specification distinguish between behaviour in first-party and third-party contexts? +
- When an HTTP request includes the
Originheader (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use ofOriginis not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, theOriginheader’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
+
+ - How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? +
- No different than
browser’s 'normal' state
.
+
+ - Does this specification have both "Security Considerations" and "Privacy Considerations" sections? +
- Yes, in Security Considerations and Privacy Considerations. + +
- Do features in your specification enable origins to downgrade default security protections? +
- No. +
References
+Normative References
+-
+
- [FETCH] +
- Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/ +
- [FOAF] +
- FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec +
- [INFRA] +
- Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/ +
- [RDF-SCHEMA] +
- RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ +
- [RDF11-CONCEPTS] +
- RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ +
- [RFC2119] +
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
- [RFC3864] +
- Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864 +
- [RFC3986] +
- Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986 +
- [RFC5789] +
- PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html +
- [RFC6454] +
- The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454 +
- [RFC7231] +
- Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html +
- [RFC8274] +
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174 +
- [RFC8288] +
- Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html +
- [TURTLE] +
- RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/ +
- [VCARD-RDF] +
- vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/ +
- [WEBARCH] +
- Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/ +
- [WEBID] +
- WebID 1.0. Henry Story; Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/ +
Informative References
+-
+
- [LDP] +
- Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/ +
- [ODRL-MODEL] +
- ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/ +
- [SECURITY-PRIVACY-QUESTIONNAIRE] +
- Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/ +
- [SOLID-PROTOCOL] +
- Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol +
- [SPARQL11-QUERY] +
- SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/ +
- [SPARQL11-UPDATE] +
- SPARQL 1.1 Update. Paula Gearon; Alexandre Passant; Axel Polleres. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-update/ +