From 5b3753a8afc36fce2dc02ca49ae2391eed7dbc0d Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Sun, 26 Apr 2026 16:15:26 +0100
Subject: [PATCH 1/5] Placeholder access-control-language sections pending CG
consensus
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Adds a top-of-document warning banner and replaces the WAC/ACP
content in §2 with placeholders marked 'subject to discussion before
inclusion':
- §SOTD: warning banner pointing at the affected sections and #783.
- §2 specifications table: WAC version cell becomes 'Subject to
discussion before inclusion'; new ACP row added with the same.
- TOC: §2.4 Access Control Policy added; WebID 1.0 and Solid WebID
Profile renumbered to §2.5/2.6.
- §2.1 Solid Protocol commentary: WAC-encouragement bullet, the
March 2026 survey note, and the architectural-separation bullet
are removed and replaced with a one-line pointer to §2.3 / §2.4.
- §2.3 Web Access Control: content replaced with a 'subject to
discussion before inclusion' warning, pointing at PR #783.
- §2.4 Access Control Policy (new): same placeholder structure.
Allows the wider Solid26 launch to proceed without holding on the
unresolved WAC/ACP wording. Once #783 reaches consensus, this
placeholder branch will be replaced with the agreed text.
---
solid26.html | 75 ++++++++++++++++++++--------------------------------
1 file changed, 29 insertions(+), 46 deletions(-)
diff --git a/solid26.html b/solid26.html
index 99a3d789..33406bdd 100644
--- a/solid26.html
+++ b/solid26.html
@@ -278,6 +278,10 @@
This document is intended to provide implementation guidance for the Solid specifications collected in the Solid26 release. The content of this guide is informative and non-normative. It may be updated, replaced, or obsoleted by other documents at any time.
@@ -295,8 +299,9 @@ Table of Contents
2.1 Solid Protocol
2.2 Solid-OIDC
2.3 Web Access Control
- 2.4 WebID 1.0
- 2.5 Solid WebID Profile
+ 2.4 Access Control Policy
+ 2.5 WebID 1.0
+ 2.6 Solid WebID Profile
@@ -358,9 +363,14 @@ Specifications
Web Access Control
- (CG-DRAFT, v1.0.0, 2024-05-12)
+ Subject to discussion before inclusion
Link
+
+ Access Control Policy
+ Subject to discussion before inclusion
+ Link
+
@@ -375,48 +385,8 @@ Solid Protocol
If a server does not support HTTP PATCH, a client can read-modify-write via GET then PUT. To avoid the lost-update problem [W3C — Editing the Web ], issue the PUT conditionally with If-Match carrying the ETag returned from the GET; the server responds with 412 Precondition Failed if the resource has changed in the interim. If only Last-Modified is exposed, If-Unmodified-Since serves the same role, though its one-second resolution is coarser than ETag-based validation. See RFC 9110 § Validator Fields for the full mechanics.
-
- Servers are strongly encouraged to implement Web Access Control (WAC ), see below .
-
-
-
Note
-
The March 2026 implementation survey yields the following results (archived ):
-
-
- For WAC, the data shows 13 server-side implementations, deployment in 11 services, and 19 client-side implementations.
- WAC is considered the pragmatic, user-friendly, and extensible standard that effectively covers nearly all of the use cases from current Solid Apps.
-
-
- For ACP, the data shows 4 server-side implementations, deployment in 1 service, and 4 client-side implementations.
- ACP is considered an expressive and complex alternative that might be chosen to satisfy corresponding use-case specific requirements.
-
-
-
The data shows that most clients implement only one access control language, despite the Solid Protocol requiring Clients to conform to both WAC and ACP.
-
-
- In case WAC seems not to satisfy implementers' requirements, implementers are strongly encouraged to verify their understanding of the matter in community discussion by providing feedback to the community.
- If WAC is not able to satisfy the requirements, implementers might consider ACP or other suitable mechanisms to achieve their goals.
- Client implementers are advised to consider that their Client implementation will not be able to interoperate with every conforming Server their Client might encounter.
-
-
-
-
- Some Clients might desire to update access control on particular resources, e.g., for sharing a user's data with another user or application.
- In such a case, Clients are strongly encouraged to rely on or make use of conforming implementations that are independently tested and verified, e.g., through open test suites and publicly documented implementation reports.
- Servers might only allow such tested and verified conformant Clients to modify access control rules.
-
-
- Implementers of Clients are advised to consider whether their Client implementation should actually attempt to modify access rules at all:
- An architectural separation between a Client executing application-specific logic and a Client executing authorization-related logic might be beneficial in terms of separation of concerns, maintainability, and re-usability of software components [BKY+24 ].
- Such separation allows Clients to rely on an externally tested and verified Client already implementing of authorization-related logic.
- Such approach to modifying access control rules might rely on
-
-
- access requests to update access control rules accordingly on a Server
- issued by the application-logic Client
- processed by a particular Client that is able and trusted to manage access controls (such as an access management or authorization application)
-
-
+ The Solid Protocol's access-control requirements (Web Access Control and Access Control Policy) are subject to discussion before inclusion . See § Web Access Control and § Access Control Policy .
+
@@ -442,8 +412,21 @@ EDITORS' Note
Web Access Control
-
Web Access Control (CG-DRAFT, v1.0.0, 2024-05-12) is included.
+
+
Subject to discussion before inclusion
+
Inclusion and wording of Web Access Control in this Implementation Guide is currently under CG discussion. The proposed text is being worked on in PR #783 and will land here once consensus is reached.
+
+
+
+
+ Access Control Policy
+
+
+
Subject to discussion before inclusion
+
Inclusion and wording of Access Control Policy in this Implementation Guide is currently under CG discussion. The proposed text is being worked on in PR #783 and will land here once consensus is reached.
+
+
From 14e199dfddbfa4da73a225a4b13ac477d876a5d7 Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Sun, 26 Apr 2026 16:22:24 +0100
Subject: [PATCH 2/5] =?UTF-8?q?Restore=20the=20'Some=20Clients...'=20bulle?=
=?UTF-8?q?t=20in=20=C2=A72.1=20Solid=20Protocol?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Keep the architectural-separation guidance for Clients managing
access controls; only the WAC/ACP-encouragement bullet and the
March 2026 survey note remain replaced by the placeholder.
---
solid26.html | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/solid26.html b/solid26.html
index 33406bdd..6f280a76 100644
--- a/solid26.html
+++ b/solid26.html
@@ -387,6 +387,24 @@ Solid Protocol
The Solid Protocol's access-control requirements (Web Access Control and Access Control Policy) are subject to discussion before inclusion . See § Web Access Control and § Access Control Policy .
+
+
+ Some Clients might desire to update access control on particular resources, e.g., for sharing a user's data with another user or application.
+ In such a case, Clients are strongly encouraged to rely on or make use of conforming implementations that are independently tested and verified, e.g., through open test suites and publicly documented implementation reports.
+ Servers might only allow such tested and verified conformant Clients to modify access control rules.
+
+
+ Implementers of Clients are advised to consider whether their Client implementation should actually attempt to modify access rules at all:
+ An architectural separation between a Client executing application-specific logic and a Client executing authorization-related logic might be beneficial in terms of separation of concerns, maintainability, and re-usability of software components [BKY+24 ].
+ Such separation allows Clients to rely on an externally tested and verified Client already implementing of authorization-related logic.
+ Such approach to modifying access control rules might rely on
+
+
+ access requests to update access control rules accordingly on a Server
+ issued by the application-logic Client
+ processed by a particular Client that is able and trusted to manage access controls (such as an access management or authorization application)
+
+
From 03d2c29f58b87ae2d32aa50bc5035dde09a4c168 Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Sun, 26 Apr 2026 16:22:57 +0100
Subject: [PATCH 3/5] =?UTF-8?q?Wrap=20=C2=A72.1=20WAC/ACP=20placeholder=20?=
=?UTF-8?q?bullet=20in=20a=20warning=20box?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Visual consistency with the placeholders in §2.3 and §2.4.
---
solid26.html | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/solid26.html b/solid26.html
index 6f280a76..3f030f59 100644
--- a/solid26.html
+++ b/solid26.html
@@ -385,7 +385,10 @@ Solid Protocol
If a server does not support HTTP PATCH, a client can read-modify-write via GET then PUT. To avoid the lost-update problem [W3C — Editing the Web ], issue the PUT conditionally with If-Match carrying the ETag returned from the GET; the server responds with 412 Precondition Failed if the resource has changed in the interim. If only Last-Modified is exposed, If-Unmodified-Since serves the same role, though its one-second resolution is coarser than ETag-based validation. See RFC 9110 § Validator Fields for the full mechanics.
- The Solid Protocol's access-control requirements (Web Access Control and Access Control Policy) are subject to discussion before inclusion . See § Web Access Control and § Access Control Policy .
+
+
Subject to discussion before inclusion
+
The Solid Protocol's access-control requirements (Web Access Control and Access Control Policy) are subject to discussion before inclusion. See § Web Access Control and § Access Control Policy .
+
From fd5646075166c58bbd9d0933a175eeb3b0a12d71 Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Sun, 26 Apr 2026 16:26:15 +0100
Subject: [PATCH 4/5] Switch placeholder boxes to .issue and broaden the banner
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The W3C base stylesheet styles .note and .issue but not .warning, so
the previous placeholders rendered without a visual box. Switch all
four to class="issue".
Also broaden the top-of-doc banner: state explicitly that the whole
document is a draft so all parts may change, with the highlighted
'subject to discussion' sections (§Web Access Control and §Access
Control Policy) at primary risk.
---
solid26.html | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/solid26.html b/solid26.html
index 3f030f59..c3b7a99e 100644
--- a/solid26.html
+++ b/solid26.html
@@ -278,9 +278,9 @@
Status of This Document
This document was published by the W3C Solid Community Group . It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups .
This document is intended to provide implementation guidance for the Solid specifications collected in the Solid26 release. The content of this guide is informative and non-normative. It may be updated, replaced, or obsoleted by other documents at any time.
Comments regarding this document are welcome. Please file issues on GitHub .
-
+
Notice
-
Some parts of this document are in the final stages of consensus building and are marked subject to discussion before inclusion . The currently affected sections are § Web Access Control and § Access Control Policy ; the access-control-language wording is being worked on in PR #783 and will land here once consensus is reached.
+
This document is currently a draft; all parts are subject to change. The pieces marked subject to discussion before inclusion are at primary risk: § Web Access Control and § Access Control Policy . The access-control-language wording is being worked on in PR #783 and will land here once consensus is reached.
@@ -385,7 +385,7 @@ Solid Protocol
If a server does not support HTTP PATCH, a client can read-modify-write via GET then PUT. To avoid the lost-update problem [W3C — Editing the Web ], issue the PUT conditionally with If-Match carrying the ETag returned from the GET; the server responds with 412 Precondition Failed if the resource has changed in the interim. If only Last-Modified is exposed, If-Unmodified-Since serves the same role, though its one-second resolution is coarser than ETag-based validation. See RFC 9110 § Validator Fields for the full mechanics.
-
+
Subject to discussion before inclusion
The Solid Protocol's access-control requirements (Web Access Control and Access Control Policy) are subject to discussion before inclusion. See § Web Access Control and § Access Control Policy .
@@ -433,7 +433,7 @@
EDITORS' Note
Web Access Control
-
+
Subject to discussion before inclusion
Inclusion and wording of Web Access Control in this Implementation Guide is currently under CG discussion. The proposed text is being worked on in PR #783 and will land here once consensus is reached.
@@ -443,7 +443,7 @@
Subject to discussion before inclusion
Access Control Policy
-
+
Subject to discussion before inclusion
Inclusion and wording of Access Control Policy in this Implementation Guide is currently under CG discussion. The proposed text is being worked on in PR #783 and will land here once consensus is reached.
From 0df85271957ace0cc454997f7efb2a6097c009bc Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Sun, 26 Apr 2026 16:34:38 +0100
Subject: [PATCH 5/5] Link the ACP row in the specifications table to
TR/2022/acp-20220518
---
solid26.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/solid26.html b/solid26.html
index c3b7a99e..c0bff750 100644
--- a/solid26.html
+++ b/solid26.html
@@ -367,7 +367,7 @@
Specifications
Link
- Access Control Policy
+ Access Control Policy
Subject to discussion before inclusion
Link