Web Access Control

Version 1.0.0-cr.1, Candidate Recommendation, 2022-07-05

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 an Version 1.0.0-cr.1. 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 Version 1.0.0-cr.1 does not imply endorsement by the W3C Membership. This document is a Candidate Recommendation by the W3C Solid Community Group and we invite implementations. It will only change in response to important implementation feedback. 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.

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

Prefixes and 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], [ACTIVITYPUB].

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.

Servers MUST NOT directly associate more than one ACL resource to a resource.

Clients MUST 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].

When an authorized HTTP GET or HEAD request targets root container’s ACL resource, the server MUST respond with a representation.

The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

Source: issues/45

Authorization Rule

Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granting to agents the ability to perform operations on resources. Authorizations are described with RDF statements and can express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects. See the Authorization Conformance section for applicable Authorizations towards Authorization Evaluation.

Access Objects

The acl:accessTo predicate denotes the resource to which access is being granted.

The acl:default predicate denotes the container resource whose Authorization can be applied to a resource lower in the collection hierarchy.

Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

Source: issues/59

Access Modes

The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

The acl:mode predicate denotes a class of operations that the agents can perform on a resource.

acl:Read: Allows access to a class of read operations on a resource, e.g., to view the contents of a resource on HTTP GET requests.
acl:Write: Allows access to a class of write operations on a resource, e.g., to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
acl:Append: Allows access to a class of append operations on a resource, e.g., to add information, but not remove, information on HTTP POST, PATCH requests.
acl:Control: Allows access to a class of read and write operations on an ACL resource associated with a resource.

Note: Access Mode Classes

acl:Access is a superclass where specific access modes (entailing a class of operations) can be subclassed. It is not intended to be used for setting or matching access privileges.

acl:Append is a subclass of acl:Write.

Note: URI Ownership

URI ownership, as per Architecture of the World Wide Web [WEBARCH], is outside the scope of this specification, and thus cannot be changed by modifying Authorizations.

Note: Loss of Control Mitigation

It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources, such as by ensuring valid ACL resources and Authorizations, by providing administrative functions on the storage, or by implicitly granting control over all resources in a storage to owners.

Source: issues/67, issues/153, pull/264

Source: issues/33

Access Subjects

The ability of a subject to access a resource can be granted to identifiable agents, a class of agents, a group of agents, or an origin.

The acl:agent predicate denotes an agent being given the access permission.

The acl:agentClass predicate denotes a class of agents being given the access permission.

Two agent classes are defined here:

foaf:Agent: Allows access to any agent, i.e., the public.
acl:AuthenticatedAgent: Allows access to any authenticated agent.

The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

The acl:origin predicate denotes the origin of an HTTP request that is being given the access permission.

Note: Subject Verification

Servers might accept different authentication protocols as well as credential verification methods.

Note: Origin Considerations

Typical Web browsers use origin based security. While it has many limitations, it is however ubiquitous.

Issue: Client Identification

Distinguishing social entities and clients: issues/81.

Source: issues/34, issues/32, issues/59

Authorization Process

This section describes how implementations can determine the effective ACL resource of a resource and hence which set of conforming authorizations to use.

Servers process access requests by evaluating the Authorizations associated with referenced resources in order to determine whether the necessary access permissions are granted for a particular request.

Effective ACL Resource

Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform control operations.

When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

When an ACL resource associated with a resource does not have a representation (ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource might apply on every access to a member resource, in specifying Authorizations for the requested resource.

WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading towards the root container).

Effective ACL Resource Algorithm

To determine the effective ACL resource of a resource, perform the following steps. Returns string (the URI of an ACL Resource).

Let resource be the resource.
Let aclResource be the ACL resource of resource.
If resource has an associated aclResource with a representation, return aclResource.
Otherwise, repeat the steps using the container resource of resource.

Note: Effective ACL Resource Alternatives

This specification does not constrain alternative methods to determine the effective ACL resource of a resource.

Source: issues/55, issues/106, issues/130, issues/257, issues/251

Authorization Conformance

An applicable Authorization has the following properties:

At least one rdf:type property whose object is acl:Authorization.
At least one acl:accessTo or acl:default property value (Access Objects).
At least one acl:mode property value (Access Modes).
At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).

Source: issues/56, issues/57, issues/169, issues/186, issues/193, issues/17, issues/18, issues/38, issues/68, issues/78, issues/145

Authorization Evaluation

The evaluation of an authorization is concerned with finding Authorizations that match the required parameters of an operation (Authorization Conformance). Evaluation stops when all access permission requests have been granted by one or more Authorizations. Authorizations that do not match a required access permission have no effect on the outcome of the evaluation. Access is granted when conforming Authorizations are matched, otherwise access is denied.

As per determining the Effective ACL Resource of a resource, an Authorization can be evaluated explicitly (via acl:accessTo) or inherited (via acl:default) against a particular request.

When a request requires an access mode (acl:mode) which is a limitation of another access mode, then access is granted if either mode is allowed by an Authorization. For example, when a request requires acl:Append, then access will be granted to agents having acl:Write.

The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Origin Authorization).

Reading and Writing Resources

Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

Generally: read operations attempt to confirm the existence of a resource or to view the contents of a resource; write operations attempt to create, delete, or modify resources; append operations attempt to create resources or add information to existing resources; and control operations attempt to view, create, delete, or modify ACL resources.

As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.

When an operation requests to create a resource as a member of a container resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege (as needed by the operation) on the resource to be created.

When an operation requests to update a resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the resource.

When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.

Note: Container Permissions

When a server supports the creation of intermediate containers in the process of creating a resource, the server applies the same requirements for the create operation for each container.

When a server supports the recursive deletion of a container, the server applies the same requirements for the delete operation for each member resource.

Note: Reinstated Resource Permissions

Implementations might perform cleanup tasks such as deleting the ACL resource that is associated with a resource when the resource is deleted. As deleted resources can be replaced by new resources with the same URI, access permissions on the new resource can differ when the Effective ACL Resource is determined.

When an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.

Note: HTTP Method and Access Mode Mapping

When the target of the HTTP request is the ACL resource, the operation can only be allowed with the acl:Control access mode.

Having acl:Control does not imply that the agent has acl:Read or acl:Write access to the resource itself, just to its corresponding ACL resource. For example, an agent with control access can disable their own write access (to prevent accidental over-writing of a resource by an application), but be able to change their access levels at a later point (since they retain acl:Control access).

The HTTP GET method request targeting a resource can only be allowed with the acl:Read access mode.

The HTTP POST can be used to create a new resource in a container or add information to existing resources (but not remove resources or its contents) with either acl:Append or acl:Write.

As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

As the processing of HTTP PATCH method requests depends on the request semantics and content, acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

Source: issues/47, issues/132, issues/197, issues/246

Web Origin Authorization

User agents include the HTTP Origin header field to isolate different origins and permit controlled communication between origins. The Origin header warns the server that a possibly untrusted Web application is being used.

When an HTTP request includes the Origin header, the requested operation is granted on the target resource when there is a match for:

an Authorization allowing access to the requesting agent (acl:agent, acl:agentGroup, acl:agentClass);
an Authorization with an acl:origin property value that of Origin’s field-value, when the required access mode is not available to all agents (acl:agentClass foaf:Agent); and
the required access mode is allowed for the requesting agent and the origin.

When a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

Note: Access Subject and Origin Rejection Reason

Implementations are encouraged to describe reasons to reject the request in the HTTP response the difference between the access subject not being allowed and the origin associated with the HTTP request not being granted access.

Note: Trusted Origins

Implementations might implicitly allow a list of origins, such as the same-origin [RFC6454].

Authorization Matching

This section is non-normative.

This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language’s [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.

The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, e.g., <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

Example: Match an Authorization with a specific resource, agent and access mode.

PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX vcard: <http://www.w3.org/2006/vcard/ns#>

ASK {
  GRAPH $aclResource {
    ?authorization
      a acl:Authorization ;
      acl:accessTo $resource ;
      acl:agent $agent ;
      acl:mode $mode .
  }
}

ASK query matching an Authorization given inputs resource, agent and mode.

From here on, PREFIXs in the query are assumed to be present.

The following query is typically used in context of inheriting Authorizations (acl:default) from a container’s ACL resource. The query also demonstrates matching Authorizations that use a superclass of the required access mode (Access Mode Classes):

Example: Match an Authorization with a specific container resource, agent class membership and access mode.

ASK {
  GRAPH $aclResource {
    {
      ?authorization
        a acl:Authorization ;
        acl:default $containerResource ;
        acl:agentClass $agentClass ;
        acl:mode $requiredMode .
    }
    UNION
    {
      ?authorization
        a acl:Authorization ;
        acl:default $containerResource ;
        acl:agentClass $agentClass ;
        acl:mode ?mode .
      GRAPH $aclOntologyResource {
        $requiredMode rdfs:subClassOf+ ?mode .
      }
    }
  }
}

ASK query matching an Authorization given inputs containerResource, agentClass and requiredMode (which could be a subclass of another access mode).

The following query can be used to check if an agent is a member of any group that can access a resource:

Example: Match an Authorization with a specific resource, agent with any group membership, and specific access mode.

ASK {
  GRAPH $aclResource {
    ?authorization
      a acl:Authorization ;
      acl:accessTo $resource ;
      acl:agentGroup ?agentGroup ;
      acl:mode $mode .
  }
  GRAPH ?groupResource {
    ?agentGroup vcard:hasMember $agent .
  }
}

ASK query matching an Authorization given inputs resource, agent and mode.

Access Privileges

Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

Clients MUST discover access privileges on a resource by making an HTTP GET or HEAD request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

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 is submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry [RFC8288].

Relation Name: acl
Description: Asserts that the link target provides an access control resource for the link context.
Reference: https://solidproject.org/TR/wac#acl-link-relation

Source: issues/54, issues/21, issues/32

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.

Authorization Extensions

This section is non-normative.

As ACL resources are RDF sources; Authorization descriptions can be extended or limited by constraints, e.g., temporal or spatial constraints; and duties, e.g., payments, can be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

To allow access to a class of resources, implementations can use the acl:accessToClass predicate as defined in the ACL ontology.

Source: issues/10, issues/22, pull/37, issues/20

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.

This specification describes permission inheritance based on determining the Effective ACL Resource of a resource. Alternative strategies such as cumulative permissions (union of all the permissions from each ACL resource inherited from the ancestors of a resource) are allowed, but no behaviour is defined by this specification.

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.

Transfer of Authorizations between a client and server over an open network creates the potential for those rules to be modified or disclosed without proper authorization. The requirements for the WAC protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application might be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

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:Control access 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 to file:, data:, or blob: 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 Origin header (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 of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’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.

Change Log

This section is non-normative.

wac-20220705 ← wac-20210711

Changes from wac-20210711 to this version

Amend language, document details, and markup.
Update acl Link Relation definition.
Add Contributors.
Update References.
Clarify existing requirements.

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. 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

[ACTIVITYPUB]: ActivityPub. Christopher Webber; Jessica Tallon. W3C. 23 January 2018. W3C Recommendation. URL: https://www.w3.org/TR/activitypub/
[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. W3C Solid Community Group. 17 December 2021. Version 0.9.0. 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/