diff --git a/index.html b/index.html index 3c383a1..fc3ee57 100644 --- a/index.html +++ b/index.html @@ -225,7 +225,7 @@

Web Access Control

-

Editor’s Draft,

+

Editor’s Draft,

More details about this document
@@ -253,6 +253,7 @@

Web Access Control

Tim Berners-Lee
Henry Story
Sarven Capadisli
+
Christoph Braun
Created
@@ -264,7 +265,7 @@

Web Access Control

Modified
-
+
Feedback
@@ -290,7 +291,7 @@

Web Access Control

Version
-
1.0.0
+
1.1.0
Notifications Inbox
@@ -348,7 +349,7 @@

Web Access Control

-

Copyright © 2021–2024 the Contributors to Web Access Control, Editor’s Draft, under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available. All code snippets are in the public domain, CC0.

+

Copyright © 2021–2026 the Contributors to Web Access Control, Editor’s Draft, under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available. All code snippets are in the public domain, CC0.

@@ -384,7 +385,8 @@

Table of Contents

3. ACL Resources

  1. 3.1 ACL Resource Discovery
    2. -
  2. 3.2 ACL Resource Representation
    3. +
  3. 3.2 ACL Resource Condition Discovery
    4. +
  4. 3.3 ACL Resource Representation
  • @@ -393,6 +395,7 @@

    Table of Contents

  • 4.1 Access Objects
  • 4.2 Access Modes
  • 4.3 Access Subjects
    • +
  • 4.4 Access Conditions
  • @@ -404,9 +407,10 @@

    Table of Contents

    5.3 Authorization Evaluation

    1. 5.3.1 Reading and Writing Resources
      2. -
    2. 5.3.2 Web Origin Authorization
      3. -
    3. 5.3.3 Authorization Matching
      4. -
    4. 5.3.4 Access Privileges
      5. +
    5. 5.3.2 Condition Evaluation
      6. +
    6. 5.3.3 Web Origin Authorization
      7. +
    7. 5.3.4 Authorization Matching
      8. +
    8. 5.3.5 Access Privileges
    • @@ -423,8 +427,9 @@

    Table of Contents

    1. 7.1 Authorization Extensions
    2. 7.2 Access Mode Extensions
      3. -
    3. 7.3 Permission Inheritance Extensions
      4. -
    4. 7.4 Distinct Effective ACL Resource Extensions
      5. +
    5. 7.3 Access Condition Extensions
      6. +
    6. 7.4 Permission Inheritance Extensions
      7. +
    7. 7.5 Distinct Effective ACL Resource Extensions
  • @@ -453,9 +458,9 @@

    Table of Contents

    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 and meet the social requirements of decentralised applications, mechanisms for expressing and applying authorization conditions are needed.

    -

    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.

    +

    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 and meet the social requirements of decentralised applications, mechanisms for expressing and applying authorization rules.

    +

    Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization rules 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 rules 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

    @@ -473,8 +478,7 @@

    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
    @@ -495,8 +499,14 @@

    Terminology

    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.
    +
    issuer
    +
    An issuer is an agent that asserts characteristics of an agent, such as identity, role, attribute, capability, or similar.
    +
    client
    +
    A client is a software agent (application) which requests resources on behalf of an agent (possibly itself).
    origin
    An origin indicates where an HTTP request originates from [RFC6454].
    +
    condition
    +
    A condition is an additional requirement on an Authorization that is evaluated as part of Authorization Evaluation.

    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.

    @@ -557,7 +567,7 @@

    HTTP Interactions

    ACL Resources

    -

    This section describes ACL resource discovery and representation.

    +

    This section describes ACL resource discovery, condition discovery, and representation.

    ACL Resource Discovery

    @@ -581,6 +591,19 @@

    Note: URI Origin

    Source: issues/8, issues/62, issues/131, issues/176

    +
    +

    ACL Resource Condition Discovery

    +
    + + +
    +

    Note: Discovering Condition Types via Effective ACL Resource

    +
    +

    Clients do not need an additional HTTP request to discover supported condition types, since they can be obtained as part of determining the effective ACL resource.

    +
    +
    +
    +

    ACL Resource Representation

    @@ -598,7 +621,7 @@

    ACL Resource Representation

    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.

    +

    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, access subjects to specify who can access the objects, and access conditions to specify additional requirements. See the Authorization Conformance section for applicable Authorizations towards Authorization Evaluation.

    Access Objects

    @@ -651,6 +674,7 @@

    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: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:agentClass predicate denotes a class of agents being given the access permission.

    Two agent classes are defined here:

    @@ -659,7 +683,6 @@

    Access Subjects

    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

    @@ -673,14 +696,43 @@

    Note: Origin Considerations

    Typical web browsers use origin-based security to isolate content and prevent malicious interactions. While not designed to identify clients, it can complement security mechanisms such as mTLS-based authentication.

    -
    -

    Issue: Client Identification

    +

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

    +
    +
    +
    +

    Access Conditions

    +
    +

    The acl:condition predicate specifies a condition on an Authorization beyond access objects, access modes, and access subjects. The value of acl:condition entails acl:Condition. Supported condition types are discovered via ACL Resource Condition Discovery. The requirements for new access conditions is explained in the Access Condition Extensions section.

    +
    +

    Client Condition

    +
    +

    A subject agent may interact with resources using a client. An acl:ClientCondition defines which clients are permitted to act on behalf of the subject agent. The following properties are defined:

    +

    The acl:client predicate denotes a client being allowed access when acting on behalf of the subject agent.

    +

    The acl:clientGroup predicate denotes a group of agents being allowed access when acting on behalf of the subject agent. The object of an acl:clientGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    +

    The acl:clientClass predicate denotes a class of agents being allowed access when acting on behalf of the subject agent.

    +

    One client class is defined here:

    +
    +
    foaf:Agent
    +
    Allows any client, i.e., the public, on behalf of the subject agent.
    +
    +
    +
    +
    +

    Issuer Condition

    -

    Distinguishing social entities and clients: issues/81.

    +

    The ability to authenticate a subject might rely on the ability to identify the issuer of a corresponding assertion of identity, role, attribute or similar. An acl:IssuerCondition defines which issuers are trusted to make assertions about the subject agent. The following properties are defined:

    +

    The acl:issuer predicate denotes an issuer being trusted to make correct assertions about a subject agent.

    +

    The acl:issuerGroup predicate denotes a group of agents being trusted to make correct assertions about a subject agent. The object of an acl:issuerGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    +

    The acl:issuerClass predicate denotes a class of agents being trusted to make correct assertions about a subject agent.

    +

    One issuer class is defined here:

    +
    +
    foaf:Agent
    +
    Accepts assertions made by any agent, i.e., the public.
    +
    -
    -

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

    +
    +

    Source: issues/81, pull/133

    @@ -726,6 +778,7 @@

    Authorization Conformance

  • 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).
    • +
  • Any acl:condition property value (Access Conditions).

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

    @@ -771,7 +824,7 @@
    Note: HTTP Method and Access Mode Mappin
    POST
    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.
    PUT
    -
    The HTTP PUT method requests to create or replace the resource state. Creating a new resource requires acl:Append and/or acl:Write access to the container as well as acl:Write access to the (new) resource. Replacing an existing resource requires only acl:Write access to the resource itself.
    +
    The HTTP PUT method requests to create or replace the resource state. Creating a new resource requires acl:Append and/or acl:Write access to the container as well as acl:Write access to the (new) resource. Replacing an existing resource requires only acl:Write access to the resource itself.
    PATCH
    As the processing of HTTP PATCH method request depends on the request semantics and content, acl:Append can allow requests to insert but not delete operations, whereas acl:Write would allow both operations. To create a new resource, acl:Append or acl:Write access mode to the container is additionally required.
    DELETE
    @@ -782,6 +835,14 @@
    Note: HTTP Method and Access Mode Mappin

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

    +
    +

    Condition Evaluation

    +
    +

    When an Authorization includes one or more acl:condition properties, the server MUST only consider conditions whose types are signalled via ACL Resource Condition Discovery. Conditions whose types are not signalled are not used in Authorization Evaluation.

    +

    When an Authorization includes one or more acl:condition properties whose types are signalled, the server MUST match an Authorization only when all such conditions are satisfied.

    +

    This specification defines condition types in Access Conditions. Additional condition types can be defined as per Authorization Extensions.

    +
    +

    Web Origin Authorization

    @@ -875,6 +936,23 @@

    Authorization Matching

    }

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

    +

    The following query demonstrates matching an Authorization that includes multiple acl:condition values:

    +
    +
    Example: Match an Authorization with a specific resource, agent, access mode, client and issuer conditions.
    + 
    ASK {
+  GRAPH $aclResource {
+    ?authorization
+      a acl:Authorization ;
+      acl:accessTo $resource ;
+      acl:agent $agent ;
+      acl:mode $mode ;
+      acl:condition
+        [ a acl:ClientCondition ; acl:client $client ] ,
+        [ a acl:IssuerCondition ; acl:issuer $issuer ] .
+  }
+}
    +

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

    +
    @@ -957,6 +1035,12 @@

    Access Mode Extensions

    Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.

    +
    +

    Access Condition Extensions

    +
    +

    An extension to access conditions is any condition type not described in this specification (Access Conditions), including foreign-namespaced types, which need not explicitly declare a acl:Condition. Consumers of Authorizations that encounter condition types they do not support MUST NOT stop processing or signal an error and MUST continue processing the access conditions as if those properties were not present.

    +
    +

    Permission Inheritance Extensions

    @@ -988,6 +1072,9 @@

    Security Considerations

    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 HTTP Message Signatures. 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.

    +

    Implementations are encouraged to consider scenarios in which Authorizations granting acl:Control are client-agnostic and issuer-agnostic, avoiding inadvertent loss of control if a client or issuer becomes unavailable or untrustworthy, as well as scenarios in which restricting control access to specific clients or issuers could expose the controller to manipulation through a malicious client or issuer.

    +

    Implementations are strongly encouraged to be aware that Authorizations including acl:condition evaluated by a server without condition support could result in access rights broader than those intended by the original Authorization. Similarly, clients that do not support a condition type will process the Authorization without evaluating that condition. System operators are strongly encouraged to verify Authorizations with conditions against the condition capabilities of the server prior to deployment.

    +

    Implementations are encouraged to consider granting acl:Control access using an acl:Condition to clients known to support conditions, to preserve Authorization integrity, and to reduce the risk of inadvertent condition removal by condition-unaware clients.

    @@ -997,6 +1084,7 @@

    Privacy Considerations

    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.

    +

    Implementations are encouraged to be aware that acl:ClientCondition and acl:IssuerCondition in an ACL resource extend the existing exposure of agent information to other agents with acl:Control access, additionally revealing which client applications and identity providers an agent might use.

    @@ -1044,7 +1132,7 @@

    Security and Privacy Review

    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.
    +
    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.
    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?
    @@ -1084,6 +1172,66 @@

    Changelog

    Document Amend language and document details. + + 4 + #acl-resource-condition-discovery + Add requirements for ACL Resource Condition Discovery. + + + 4 + #access-conditions + Add Access Conditions section describing the condition requirement in an Authorization. + + + 4 + #authorization-conformance + Update Authorization Conformance to include acl:condition as part of an applicable Authorization. + + + 4 + #condition-evaluation + Add Condition Evaluation section describing the evaluation of conditions and their conjunctive requirement. + + + 2 + #match-accessto-agent-mode-conditions + Add example query demonstrating access conditions with client condition and issuer condition. + + + 2 + #consider-client-issuer-agnostic-control + Add security consideration advisement for client-issuer-agnostic control scenarios. + + + 2 + #consider-condition-legacy + Add security consideration advisement for condition-unaware server scenarios. + + + 2 + #consider-client-issuer-privacy + Add privacy consideration advisement for client and issuer information exposure. + + + 2 + #security-privacy-review-first-third-party + Amend first- and third-party context in security and privacy review. + + + 2 + #condition-discovery-via-effective-acl-resource + Add note about discovering condition types via effective ACL resource without additional requests. + + + 4 + #access-condition-extensions + Add Access Condition Extensions section for describing the extension mechanism for new condition types. + + + 2 + #consider-condition-control + Add security consideration advisement for preserving Authorization integrity with conditions. + @@ -1111,11 +1259,12 @@

    Changelog

    Acknowledgements

    The Community Group gratefully acknowledges the work that led to the creation of this specification, and extends sincere appreciation to those individuals that worked on technologies and specifications that deeply influenced our work.

    -

    The Community Group would like to thank the following individuals for their useful comments, both large and small, that have led to changes to this specification over the years:

    +

    The Community Group thanks the following individuals, listed in alphabetical order by full name, for their helpful comments, both large and small, which have contributed to changes in this specification over the years.

    • Aaron Coburn
    • Abdurrahman Ibrahim Ghanem
    • Alain Bourgeois
      • +
    • Alexander James Phillips
    • Amy Guy
    • Andreas Kuckartz
    • Andrei Sambra
      • @@ -1126,6 +1275,7 @@

      Acknowledgements

    • Benjamin Goering
    • Beth Porter
    • Bob Ferris
      • +
    • Christoph Braun
    • Dan Brickley
    • David Booth
    • dbernstein
      • @@ -1167,6 +1317,7 @@

      Acknowledgements

    • Pierre-Antoine Champin
    • Pieter Colpaert
    • Reese Hodge
      • +
    • Ross Horne
    • Ruben Taelman
    • Ruben Verborgh
    • Sandro Hawke