Web Access Control

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.

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.

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

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

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.

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

Source: issues/45

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

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.

Source: issues/33

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.

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

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

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

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

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

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

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 {
  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 {
  GRAPH $aclResource {
    ?authorization
      a acl:Authorization ;
      acl:accessTo $resource ;
      acl:agentGroup ?agentGroup ;
      acl:mode $mode .
  }
  GRAPH ?groupResource {
    ?agentGroup vcard:hasMember $agent .
  }
}

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.

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

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

Source: issues/54, issues/21

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

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.

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.

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.

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.

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.

This section is non-normative.

This section is non-normative.

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.