diff --git a/index.html b/index.html index 6c1baf22..ab9a88ad 100644 --- a/index.html +++ b/index.html @@ -118,6 +118,13 @@

Work Items

Current Stage + + + Solid26: Implementation Guide + https://github.com/solid/specification + CG-DRAFT + + Solid Protocol diff --git a/solid26.html b/solid26.html new file mode 100644 index 00000000..5b235c9b --- /dev/null +++ b/solid26.html @@ -0,0 +1,495 @@ + + + + + Solid26: Implementation Guide + + + + + + + + +
+
+
+

Solid26: Implementation Guide

+

Draft Community Group Report,

+
+ More details about this document +
+
This version
+
https://solidproject.org/TR/solid26
+
+
+
Latest published version
+
https://solidproject.org/TR/solid26
+
+
+
Editors
+
Jesse Wright (University of Oxford)
+
Christoph Braun (FZI Forschungszentrum Informatik)
+
+
+
Published
+
+
+
+
Modified
+
+
+
+
Feedback
+
GitHub solid/specification (pull requests, new issue, open issues)
+
+
+
Language
+
English
+
+
+
Document Type
+
Implementation Guide
+
+
+

Copyright © 2026 the Contributors to Solid26: Implementation Guide, under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

+
+
+
+
+

Abstract

+
+

This document is an implementation guide for Solid26 — a snapshot of the most mature and widely implemented Solid specification versions, collected to help developers and organisations identify a common baseline. It provides practical guidance for implementing the Solid specifications included in this collection.

+
+
+
+

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.

+
+
+ + +
+

Introduction

+
+

+ The Solid Technical Reports comprise multiple specification documents with differing levels of maturity. + The Solid Protocol bundles the specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way. + Solid26 points implementers to fixed versions of the Solid Protocol and its sub-specifications, a stable snapshot of the specifications to build against today. + Solid26 selects for the most widely implemented specification versions at the time of this document's publication. +

+

This document does not define new normative requirements, but rather identifies and collects the specifications needed to build interoperable Solid applications and servers.

+
+
+ +
+

Specifications

+
+

This Solid26 Implementation Guide recommends the following specification snapshots.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
SpecificationVersionDetails
Solid Protocol(CG-DRAFT, v0.11.0, 2024-05-12)Link
Solid-OIDC(v0.1.0, 2022-03-28)Link
Web Access Control(CG-DRAFT, v1.0.0, 2024-05-12)Link
+ +
+

Solid Protocol

+
+

The Solid Protocol (CG-DRAFT, v0.11.0, 2024-05-12) is included with the following comments:

+
    +
  • +

    Clients might encounter Servers that do not support § 5.3.1 Modifying Resources Using N3 Patches despite it being required by the Solid Protocol. Clients can use Allow headers to determine if a Server supports HTTP PATCH requests.

    + +

    If a server does not support HTTP PATCH requests, the client can HTTP GET the resource, apply the change locally, and then HTTP PUT the resource back. If the server supports ETag headers or Last-Modified headers, clients can achieve the concurrency-control behaviour of HTTP PATCH by issuing a conditional PUT. ETag-based validation is more precise than date-based validation and should be preferred when a server supports both, because Last-Modified has only one-second resolution and may not reflect sub-second changes.

    + +

    The flow is:

    + +
      +
    • On GET, the server returns an ETag — an opaque validator identifying the current state of the resource (often derived from a content hash, but the exact derivation is up to the server). For example, imagine the server returns ETag: "xyzzy".
      • +
    • The client then makes a conditional PUT using the If-Match header: If-Match: "xyzzy". The server applies the PUT only if the resource's current ETag still matches "xyzzy"; otherwise it responds with 412 Precondition Failed. This guarantees the resource has not changed on the server between the GET and the PUT.
      • +
    • The equivalent using dates is If-Unmodified-Since paired with the Last-Modified value from the GET response. Note that If-Modified-Since is the header used for cache revalidation on GET, not for lost-update prevention on PUT.
      • +
    + +

    Note that If-Match uses strong comparison, so weak ETags (those prefixed with W/) will not match.

    +
    • +
  • +

    + 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)
      • +
    +
    • +
+

+
+
+ +
+

Solid-OIDC

+
+

Solid-OIDC (v0.1.0, 2022-03-28) is included with the following comments:

+
    +
  • +

    Despite Solid26 including Solid-OIDC v0.1.0, it is not widely implemented. In particular, the Solid-OIDC recommended flow of User-Managed Access (UMA) is not supported by any open source Solid Server implementation. Current implementations rely on the access token issued by the OpenID Provider of the user to authenticate the user at a Solid Storage.

    +
    • +
+
+

EDITORS' Note

+

+ A corresponding Group Note document that accurately reflects current implementations is being drafted by Christoph Braun. This PR is waiting for that document to be available and ready to reference before merging. +

+
+
+
+ +
+

Web Access Control

+
+

Web Access Control (CG-DRAFT, v1.0.0, 2024-05-12) is included.

+
+
+ +
+
+ +
+

Implementation Guidance

+
+ +
+

WebID

+
+
+

Note

+

Work in progress: the content from the WebID guidance document is to be integrated into this section.

+
+
+
+
+
+ +
+

References

+
+
+
[SOLID-PROTOCOL]
+
Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Kjetil Kjernsmo. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 0.11.0. URL: https://solidproject.org/TR/2024/protocol-20240512
+ +
[SOLID-OIDC]
+
Solid-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 28 March 2022. Version 0.1.0. URL: https://solidproject.org/TR/2022/oidc-20220328
+ +
[WAC]
+
Web Access Control. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solidproject.org/TR/2024/wac-20240512
+ +
[BKY+24]
+
+ AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting. + Andreas Both; Thorsten Kastner; Dustin Yeboah; Christoph Braun; Daniel Schraudner; Sebastian Schmid; Tobias Käfer; Andreas Harth. + ICWE 2024: 199-214. + URL: https://publikationen.bibliothek.kit.edu/1000172187/post +
+
+
+
+ +
+
+
+ +