From 6e5a2ec8cb9f086e15b4fef0e4942f7f725afac1 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 24 Mar 2026 10:06:16 +0100 Subject: [PATCH 01/13] Add condition to authorization evaluation --- index.html | 168 +++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 145 insertions(+), 23 deletions(-) diff --git a/index.html b/index.html index 3c383a1..fc6237d 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
    • @@ -453,9 +457,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 +477,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 +498,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 +566,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 +590,13 @@

    Note: URI Origin

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

    +
    +

    ACL Resource Condition Discovery

    +
    + + +
    +

    ACL Resource Representation

    @@ -598,7 +614,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 +667,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 +676,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 +689,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.

    +
    +

    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 relies on the ability to identify the issuer of the corresponding assertion. 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 +771,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 +817,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 +828,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 +929,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.

    +
    @@ -988,6 +1059,8 @@

    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 values evaluated by a server without condition support, such as following data migration from a conditions-aware server, could result in elevated access rights. Implementations are strongly encouraged to verify Authorizations with conditions against the condition capabilities of the server prior to deployment.

    @@ -997,6 +1070,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 uses.

    @@ -1044,7 +1118,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 +1158,51 @@

    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. + @@ -1116,6 +1235,7 @@

    Acknowledgements

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

    Acknowledgements

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

    Acknowledgements

  • Pierre-Antoine Champin
  • Pieter Colpaert
  • Reese Hodge
    • +
  • Rosse Horne
  • Ruben Taelman
  • Ruben Verborgh
  • Sandro Hawke
    • From 1b23f4137532d31b954437bd01fe1096b337a096 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 31 Mar 2026 23:55:38 +0200 Subject: [PATCH 02/13] Fix typo on Ross's name Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com> --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index fc6237d..c98ae38 100644 --- a/index.html +++ b/index.html @@ -1288,7 +1288,7 @@

    Acknowledgements

  • Pierre-Antoine Champin
  • Pieter Colpaert
  • Reese Hodge
    • -
  • Rosse Horne
    • +
  • Ross Horne
  • Ruben Taelman
  • Ruben Verborgh
  • Sandro Hawke
    • From cafa1747f5ff952acb94de3b2d549e7e67b1d995 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 00:00:34 +0200 Subject: [PATCH 03/13] Relax wording around authentication Co-authored-by: Christoph Braun --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index c98ae38..9ab35eb 100644 --- a/index.html +++ b/index.html @@ -713,7 +713,7 @@

    Client Condition

    Issuer Condition

    -

    The ability to authenticate a subject relies on the ability to identify the issuer of the corresponding assertion. An acl:IssuerCondition defines which issuers are trusted to make assertions about the subject agent. The following properties are defined:

    +

    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.

    From ff73d84d613b3b51c38b9b19f91ada9a361a73bd Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 00:04:49 +0200 Subject: [PATCH 04/13] Fix wording on an agent might use client/issuer Co-authored-by: Christoph Braun --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 9ab35eb..3d763be 100644 --- a/index.html +++ b/index.html @@ -1070,7 +1070,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 uses.

    +

    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.

    From cad6edce347f001c4ef73183d02150abb39f804a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 00:08:38 +0200 Subject: [PATCH 05/13] Clarify purpose of client-link-condition by reordering the sentence Resolves comment https://github.com/solid/web-access-control-spec/pull/134#discussion_r300871555 --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 3d763be..9bdf791 100644 --- a/index.html +++ b/index.html @@ -594,7 +594,7 @@

    Note: URI Origin

    ACL Resource Condition Discovery

    - +
    From 7c315bd922bec39dd12cb9e3268f522be4b0032a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 00:11:31 +0200 Subject: [PATCH 06/13] Add condition-discovery-via-effective-acl-resource --- index.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/index.html b/index.html index 9bdf791..abd9087 100644 --- a/index.html +++ b/index.html @@ -595,6 +595,12 @@

    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.

    +
    +
    From a5fbf5071c8cbe1d26077acedca3394328b088ca Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 00:30:20 +0200 Subject: [PATCH 07/13] Update acknowledgements text to indicate alphabetical order by full name listing --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index abd9087..bdcc6ab 100644 --- a/index.html +++ b/index.html @@ -1236,7 +1236,7 @@

    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
      • From 215b62bd2d6dff984ff515b490be6a68186cf4d4 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 1 Apr 2026 01:30:50 +0200 Subject: [PATCH 08/13] Add changelog entry condition-discovery-via-effective-acl-resource --- index.html | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/index.html b/index.html index bdcc6ab..b712200 100644 --- a/index.html +++ b/index.html @@ -1209,6 +1209,11 @@

      Changelog

      #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. + From 8e7580409d18417b3acc27f8c90e8b7abdc83336 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Apr 2026 13:10:43 +0200 Subject: [PATCH 09/13] Add access-condition-extensions section for describing the extension mechanism for new condition types --- index.html | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index b712200..59cf740 100644 --- a/index.html +++ b/index.html @@ -427,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
    • @@ -701,7 +702,7 @@

      Note: Origin Considerations

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

      @@ -1034,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

      From 0c0a6f5f82a75a60e3d3f12dc790cafaa46d5b7f Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Apr 2026 13:12:14 +0200 Subject: [PATCH 10/13] Add security consideration advisement for preserving Authorization integrity with conditions in consider-condition-control --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 59cf740..787581c 100644 --- a/index.html +++ b/index.html @@ -1073,7 +1073,7 @@

      Security Considerations

      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 values evaluated by a server without condition support, such as following data migration from a conditions-aware server, could result in elevated access rights. Implementations 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. to reduce the risk of inadvertent condition removal by condition-unaware clients.

      From 2faf11220ab4a6232bfe5a4efa3efb5b74c461db Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Apr 2026 13:13:01 +0200 Subject: [PATCH 11/13] Update consider-condition-legacy to take clients into account --- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index 787581c..17a431e 100644 --- a/index.html +++ b/index.html @@ -1073,6 +1073,7 @@

      Security Considerations

      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. to reduce the risk of inadvertent condition removal by condition-unaware clients.

      From 974d74bf9ac2b09b2d53e028ef4c389d4acae919 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Apr 2026 13:13:24 +0200 Subject: [PATCH 12/13] Update changelog and modified --- index.html | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 17a431e..ee313c9 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
      @@ -265,7 +265,7 @@

      Web Access Control

      Modified
      -
      +
      Feedback
      @@ -1222,6 +1222,16 @@

      Changelog

      #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. + From cf3c98e4d63543484519309bb7a26d588a0c3b7c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Apr 2026 18:41:26 +0200 Subject: [PATCH 13/13] Adding missing connector 'and' Co-authored-by: Christoph Braun --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ee313c9..fc3ee57 100644 --- a/index.html +++ b/index.html @@ -1074,7 +1074,7 @@

      Security Considerations

      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. to reduce the risk of inadvertent condition removal by condition-unaware clients.

      +

      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.