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

Work Items

Current Stage + + + Solid26 + https://github.com/solid/specification + CG-DRAFT + + Solid Protocol diff --git a/solid26.html b/solid26.html new file mode 100644 index 00000000..1092cc88 --- /dev/null +++ b/solid26.html @@ -0,0 +1,462 @@ + + + + + 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 as a Community Group Report. It is not a W3C Standard nor is it on the W3C Standards Track.

+

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

+ +
+

Solid Protocol

+
+

The Solid Protocol (CG-DRAFT/FINAL, v0.11.0) is included with the following comments:

+
    +
  • + Clients are strongly encouraged to implement a PATCH fallback mechanism, in case they encounter a Server that does not implement 5.3.1 Modifying Resources Using N3 Patches despite it being required by the Solid Protocol. + For example, Clients might try to use a combination of HTTP GET and HTTP PUT to work around such limitation of a non-conformant Server. +
    • +
  • + Servers are strongly encouraged to implement Web Access Control (WAC), see below. +
    +

    Note

    +

    The March 2026 implementation survey yields the following results:

    +
      +
    • + 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 as a highly powerful but complex tool that has not seen wide adoption in the community as the data indicates. +
      • +
    +

    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.

    +
    +
    • +
  • + While the Solid Protocol technically requires any Client to conform to both authorization languages, Client implementers are advised to consider whether their Client implementation should actually attempt to modify access rules at all: + A 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 approach might rely on +
      +
    • access requests to update access control rules accordingly on a Server
      • +
    • issued by the application-logic client
      • +
    • processed by either a particular Client that is able and trusted to manage access controls (such as an access management or authorization application) or by custom Server functionality
      • +
    +
    +

    [New Work Item]: Access Requests and Grants

     +

    + Access requests and their processing are currently are poposed work item to the CG. + Different approaches exist within the community; no consensus has been reached yet. + Implementers are encouraged to provide their implementation expierence as input to the community's discussion. +

    +
    +
    +

    Editor's Note (Christoph)

    +

    + Not sure if the above item provides sufficient guidance or is simply confusing due to the lack of context in the Solid Protocol for access requests altogether. + I, Christoph, am torn on the above item on access requests. Would like to hear the groups's opinion here. +

    +
    +
    • +
+
+
+ +
+

Solid-OIDC

+
+

Solid-OIDC (CG-DRAFT/FINAL, v0.1.0) 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/FINAL, 2024-05-12) is included with the following comments:

+
    +
  • + WAC is actively being maintained and developed: To officially extend WAC with functionality desired by the community, a corresponding proposal is seeking implementers' feedback (solid/web-access-control-spec#134). +
    • +
+
+
+
+
+ +
+

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. URL: https://solidproject.org/TR/protocol
+ +
[SOLID-OIDC]
+
Solid-OIDC. W3C Solid Community Group. URL: https://solidproject.org/TR/oidc
+ +
[WAC]
+
Web Access Control. W3C Solid Community Group. 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://doi.org/10.1007/978-3-031-62362-2_14 , + Postprint available at: https://publikationen.bibliothek.kit.edu/1000172187 +
+
+
+
+ +
+
+
+ +