From 5af7e45363ef18ee9ba5f0f3f7457aa566a15765 Mon Sep 17 00:00:00 2001
From: Christoph Braun
Date: Mon, 20 Apr 2026 16:19:28 +0200
Subject: [PATCH 39/46] add overview table for fixed specification versions
---
solid26.html | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/solid26.html b/solid26.html
index a096a690..87efee47 100644
--- a/solid26.html
+++ b/solid26.html
@@ -326,6 +326,33 @@ Specifications
This Solid26 Implementation Guide recommends the following specification snapshots.
+
+
Solid Protocol
From 68f852e7d8575d7bc9e745f2a1606d7950ef4b7f Mon Sep 17 00:00:00 2001
From: Christoph Braun
Date: Mon, 20 Apr 2026 17:54:48 +0200
Subject: [PATCH 40/46] Apply suggestions from code review
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Co-authored-by: Tobias Käfer <6708974+kaefer3000@users.noreply.github.com>
---
solid26.html | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/solid26.html b/solid26.html
index 87efee47..5b235c9b 100644
--- a/solid26.html
+++ b/solid26.html
@@ -400,18 +400,18 @@ Note
- Clients might desire to update access control on particular resources, e.g., for sharing a user's data with another user or application.
+ 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 are advised to consider whether their Client implementation should actually attempt to modify access rules at all:
+ 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
+ - 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 2076240e2c85d7b758d517245923d19869f4a83a Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Fri, 24 Apr 2026 02:06:35 +0100
Subject: [PATCH 41/46] solid26: WebID Guidance (#781)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* feat: boostrap webid section
* feat: enhance Solid26 guidance sections
* fix section headings
* feat: enhance WebID Profile guidance with additional validation notes and refined predicate listings
* feat: update WebID Profile note to include empirical data source for predicate usage
* feat: add clarification on non-public WebID Document retrieval in WebID Profile
* minor editorial
* chore: consistency of term "Implementors Guide" with main PR
Co-authored-by: Christoph Braun
* fix foaf predicate and note on solid:oidcIssuer
* Update solid26.html
Co-authored-by: Christoph Braun
* Add Linked Data Notifications inbox reference to WebID Profile
* Update WebID Document union process to mention ldp:inbox in discovery predicates
* remove use case specificity on authenticated webid
Co-authored-by: Christoph Braun
* Remove non-normative reference to Solid WebID Profile in comments
* Update solid26.html
Co-authored-by: Christoph Braun
* chore: remove mention of profile shapes
Co-authored-by: Christoph Braun
* Tighten WebID term definitions in §3.1
Use "HTTP URI" for the WebID definition to match the normative
section. Drop "Web resource" (not an established term) and the
"Generally public / permissioned" hedging; state the auth property
precisely where it matters.
* Bound Extended Profile Document traversal in assembly algorithm
Replace "transitively from the Preferences Document" recursion with
an explicit, bounded traversal: one level from Extended Profile
Documents linked directly off the WebID Document; no further
traversal from Preferences-linked or Type-Index-linked documents.
Introduce "discovery links" as a shorthand for
rdfs:seeAlso / foaf:isPrimaryTopicOf / owl:sameAs and reuse it
throughout §3.1.2 and §3.1.3. Add a note explaining why one level
of traversal is needed when the WebID Document is not itself in
Solid storage.
* Drop 'publicly readable' qualifier in assembly step 1
Visibility of the WebID Document is covered in §3.1.2. Step 1 only
needs to surface an error when retrieval fails.
* Recommend an editable Extended Profile Document when WebID is not in Solid storage
Address the case where the WebID Document itself cannot be modified
by Solid clients: advise linking an Extended Profile Document in
a Solid storage so clients have a writable attachment point for
profile statements.
* Require both text/turtle and application/ld+json for WebID Profile Document
Align with Solid WebID Profile §3.1 Reading Profile, which extends
WebID 1.0's Turtle-only requirement to include JSON-LD.
* Refresh profile-editor list: drop PodBrowser, add dokieli
PodBrowser is no longer actively maintained; dokieli is a
widely-used reader/writer of agent profiles.
* Clarify the predicate list ordering is advisory
Make the reader/writer contract explicit: readers should accept any
of the listed predicates as equivalent for a given field; writers
typically commit to one. The stated order is a suggested preference
and may vary by the ecosystem an application integrates with.
* Drop unused [BIO] reference
[BIO] was listed in §References but never cited in the document.
* Surface error when WebID lacks solid:oidcIssuer
A WebID without an oidcIssuer cannot authenticate via Solid-OIDC;
clients should tell the user rather than failing opaquely further
into the login flow.
* Call out that missing Preferences/Type Index documents are not errors
Not all WebIDs link a Preferences Document or Type Index documents;
clients should skip their fetch silently rather than fail.
* Use 'set union' in WebID Profile definition and assembly algorithm
* Replace document-level self-describing filter with spec-aligned statement filter
The earlier document-level 'self-describing' filter was a
solid26-specific precaution not present in Solid WebID Profile. The
current spec (§2 Discovery) states the profile is assembled by
collecting statements with the WebID as subject or object. Drop the
document-level filter; keep the statement-level filter and reword
step 6 positively to match the spec.
Also collapses §3.1.2 from two caveats to one (solid:oidcIssuer
origin) and removes the now-obsolete step 4 in §3.1.3 — which means
the 'switch steps 3 and 4' and 'explain step 4 better' colleague
asks dissolve naturally.
* Note the range of data-discovery mechanisms beyond the profile
Client-side data discovery varies across the ecosystem; list the
common mechanisms (Type Indexes, SAI, SPARQL / Quad Pattern
Fragments endpoints, fixed paths under storage root, DCAT) without
prescribing one.
* Add §3.1.4 Security Considerations for solid:oidcIssuer protection
Solid WebID Profile §Protected properties requires servers to
protect solid:oidcIssuer triples, but no known Solid server
implements this at time of publication; flag the implication for
implementers in an informational subsection.
* Remove references to WebID Profile SHACL shapes
Drop the shape-validation note in §3.1.3, the profile-shapes.ttl
reference and dagger markers in §4, and the companion 'not in the
shape' annotation. Shape documentation belongs in the WebID Profile
repo, not in this implementation guide.
* Soften predicate-list framing to 'fallbacks to consider'
Drop the SHOULD-accept-as-equivalent normative framing; present the
list as optional fallbacks applications may consider.
* Refresh predicate list from dokieli and SolidOS profile renderers
Derive the fallback ordering from what dokieli and SolidOS profile-pane
actually read: flip Name to foaf:name-first, broaden Avatar to the
full dokieli chain, add social accounts, schema:hasOccupation,
cco:skill, vcard:language, solid:preferredLanguage, schema:knows,
vcard:url. Pull ActivityStreams and SIOC into the referenced
vocabularies.
* Drop section numbers from external spec references
Per csarven (PR #781) and jeswr's agreement: section numbers in
referenced specs are not reliable across snapshots. Keep link text
as the section title only; internal cross-references within this
document keep their numbers.
* Language pass on §3.1 WebID: tighten prose, fix Implementors typo
Remove duplicated and filler phrasing across §3.1:
- Intro lists subsections (incl. new §3.1.4) without restating them.
- Term-dl header: 'For the purposes of this section' dropped.
- Fix 'Implementors Guide' typo in §3.1.1 heading.
- Compact '?webid ?p ?o, where ?webid is the WebID and each ?iss is…'
patterns to one statement-form with inline angle-bracket terms.
- Drop '(e.g. a person)' filler.
- Collapse 'MAY be hosted anywhere; it MAY, but need not, reside…' to
single clause.
- Tighten the Profile Document URI-resolution sentence, and
several notes / algorithm steps that repeated 'Extended Profile
Document' / 'Solid WebID Profile' within the same sentence.
* Soften security-note framing and restore absent-link prose
Use 'Not all Solid servers implement this protection' rather than
'No known Solid server', and restore the fuller wording about
Preferences/Type Index documents being absent.
* Replace numeric section refs with names; say 'set union of statements'
Inline section names as link text instead of '§ 3.1.1' / '§ 3.1.3'
style refs; reads naturally without relying on the TOC numbering.
Both 'set union' occurrences now read 'set union of statements'
to make the RDF-graph semantics explicit.
* Drop the 'pinned specifications' framing
Per csarven: framing certain specs as 'pinned' reads as gatekeeping
and adds no value for the reader. Rephrase the §3.1 intro so
requirements and common assumptions are stated as drawn from the
Solid26 Implementation Guide specifications, and trim the §3.1.2
sub-bullet to 'These specifications do not preclude...'.
* Extend WebID Profile definition to match algorithm sources
The assembly algorithm unions statements from the Preferences
Document and Type Index documents as well as Extended Profile
Documents; the term definition now names all four sources.
---------
Co-authored-by: Christoph Braun
Co-authored-by: Christoph Braun
---
solid26.html | 221 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 215 insertions(+), 6 deletions(-)
diff --git a/solid26.html b/solid26.html
index 5b235c9b..abf71a3f 100644
--- a/solid26.html
+++ b/solid26.html
@@ -295,14 +295,25 @@ 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
3. Implementation Guidance
- - 3.1 WebID
+ -
+
3.1 WebID
+
+ - 3.1.1 Requirements derivable from Solid26 Implementation Guide specifications
+ - 3.1.2 Common assumptions not required by Solid26 Implementation Guide specifications
+ - 3.1.3 Assembling the Profile
+ - 3.1.4 Security Considerations
+
+
+ 4. Guidance for clients
References
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.
+ Clients might encounter Servers that do not support 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.
@@ -445,6 +456,23 @@ Web Access Control
+
+ WebID 1.0
+
+
WebID 1.0 (W3C Editor's Draft, 5 March 2014) is included.
+
Solid WebID Profile
+
+
The Solid WebID Profile (CG Draft Report, v1.0.0, 12 May 2024) is included with the following comments:
+
+
Implementation Guidance
WebID
-
+
+
This section gives WebID implementation guidance for the Solid26 Implementation Guide. It covers requirements and common assumptions drawn from the Solid26 Implementation Guide specifications, a profile assembly algorithm, and security considerations. Client-side guidance is given separately.
+
+
Terms used in this section:
+
+ - WebID
+ - An HTTP URI that denotes an agent [WEBID], [SOLID-PROTOCOL].
+ - WebID Profile Document
+ - The document obtained by dereferencing a WebID.
+ - Extended Profile Document
+ - A further document linked from the WebID Profile Document that contains additional statements about the WebID; retrieval may require authentication.
+ - Preferences Document
+ - A document, linked from the agent's WebID Profile via
pim:preferencesFile, that holds settings and pointers to private data; typically accessible only to the agent or a delegate.
+ - WebID Profile
+ - The RDF graph [RDF11-CONCEPTS] formed by the set union of statements drawn from the WebID Profile Document, any Extended Profile Documents, the Preferences Document, and the Type Index documents, assembled per the common assumptions below.
+
+
+
+ Requirements derivable from Solid26 Implementation Guide specifications
+
+
+
+
+ Common assumptions not required by Solid26 Implementation Guide specifications
+
+
+ -
+ The WebID Document is a public resource (i.e. an unauthenticated HTTP
GET on the WebID URI returns the Profile) [WebID 1.0 § Processing the WebID Profile].
+
+ - These specifications do not preclude authenticated retrieval of a non-public WebID Document by a server acting as a client, though current server implementations generally do not support it.
+
+
+ -
+ The
pim:storage statement in the WebID Profile is the only sound mechanism for discovering an agent's storages. The storageDescription Link header is not to be used for this purpose: a WebID Document hosted in a storage does not imply the WebID owns that storage [Solid Protocol § Privacy Considerations].
+
+ -
+ The WebID Profile is assembled by collecting all statements that have the WebID as subject or object, drawn from the WebID Document and from any Extended Profile Document linked from it via
rdfs:seeAlso, foaf:isPrimaryTopicOf, or owl:sameAs (collectively, discovery links) [Solid WebID Profile § Discovery; Solid WebID Profile § Extending a Profile; WebID 1.0 § Processing the WebID Profile]. Extended Profile Documents may require authenticated retrieval. One caveat applies:
+
+ solid:oidcIssuer is honoured only from the WebID Document; statements of the form ?webid solid:oidcIssuer ?iss in Extended Profile Documents are ignored.
+
+
+
+
+
+ Assembling the Profile
+
+
+
Per [Solid WebID Profile § Discovery], the full profile is the union of statements in:
+
+ - the WebID Profile Document;
+ - Extended Profile Documents directly linked from the WebID Document via discovery links, and Extended Profile Documents that those in turn link by discovery links;
+ - the agent's Preferences Document (linked via
pim:preferencesFile) and the Extended Profile Documents it links by discovery links;
+ - the agent's public and private Type Index documents (linked via
solid:publicTypeIndex and solid:privateTypeIndex).
+
+
+
To assemble it:
+
+ GET the WebID Document. If it cannot be retrieved, surface a clear error.GET each linked document: Extended Profile Documents via discovery links, the Preferences Document via pim:preferencesFile, and Type Index documents via solid:publicTypeIndex/solid:privateTypeIndex. On 401/403 with a logged-in user, retry authenticated; Preferences and the private Type Index normally require authentication [Solid WebID Profile § Discovery, § Private Preferences]. If the WebID Document does not link a Preferences Document or Type Index documents, those fetches are skipped; their absence is not an error.- For each Extended Profile Document linked directly from the WebID Document, fetch the Extended Profile Documents it links via its discovery links. Do not traverse further: discovery links in the documents fetched by this step, in extended profiles discovered from the Preferences Document, and in Type Index documents are not followed. Use cycle detection so no document is fetched twice.
+ - Form the set union of statements from the fetched documents, then drop every
solid:oidcIssuer triple that did not originate in the WebID Document: that predicate is authoritative only when sourced there, mirroring the write protection in Solid WebID Profile § Updating Profile. Other discovery predicates (e.g. pim:storage, ldp:inbox) may legitimately appear in any of these documents.
+ - Retain only statements that have the WebID as subject or object [Solid WebID Profile § Discovery].
+
+
+
+
Note
+
When the WebID Document is not hosted in Solid storage, clients cannot add new discovery links to it. The one level of traversal from Extended Profile Documents in Solid storage lets a client attach further Extended Profile Documents (for example, at different access levels) via links it can write.
+
+
+
+
+
+ Security Considerations
+
+
[Solid WebID Profile § Protected properties] requires servers hosting a WebID Document to protect solid:oidcIssuer triples from modification by non-owners. Not all Solid servers implement this protection; on a server that does not, any agent with write access to the document can modify the WebID's issuer.
+
+
Guidance for clients
+
+
+
This section targets clients acting on behalf of a single end user — reading and writing the user's data — as opposed to authorization agents, profile editors, or server-side resource servers. The recommended flow is:
+
+
+ -
+
Obtain the user's WebID. Prompt for a WebID URI and validate that it is a well-formed http/https URI. Surface clear errors for malformed input, 404s, and responses that cannot be parsed as RDF.
+
+ -
+
Dereference the WebID. Issue an unauthenticated GET on the WebID URI. The 303 See Other redirect to the WebID Document is expected per the "Cool URIs for the Semantic Web" pattern, but other 3xx codes (301, 302, 307, 308) may also occur and must be handled.
+
+ -
+
Authenticate the user via their OpenID Provider. Read ?webid solid:oidcIssuer ?iss from the WebID Document. If no solid:oidcIssuer statement is present, surface a clear error: the WebID is not usable for Solid authentication. If more than one issuer is listed, let the user choose. Before initiating the Solid-OIDC login flow, fetch the issuer's OpenID Connect Discovery 1.0 configuration and verify that webid appears in scopes_supported [Solid-OIDC § OIDC Issuer Discovery, § OpenID Provider Conformance].
+
+ -
+
Build the WebID Profile graph by running Assembling the Profile (do not discover storages via the solid:storageDescription Link header).
+
+
+
+
+
Note
+
pim:storage may yield more than one value. When the application needs exactly one storage to write data into, prompt the user to choose rather than picking one silently.
+
+
+
+
Note
+
The Solid WebID Profile [WEBID-PROFILE] does not standardise predicates for rendering an agent's identity. For empirical data on which predicates are actually populated across the ecosystem, implementers can consult solid-load-profile, which summarises predicate usage from a sample of live Solid profiles. The list below targets foaf:Person, vcard:Individual, and schema:Person, drawing from the predicates read by existing profile renderers including SolidOS/mashlib, PodOS, Penny, and dokieli. Vocabularies referenced: FOAF [FOAF], vCard [VCARD-RDF], Schema.org [SCHEMA-ORG], ActivityStreams, SIOC, Org, and Solid Terms.
+
The following is a list of fallback predicates that applications may wish to consider using when rendering a profile. The order given for each field is a suggested preference; other orderings may be more appropriate depending on the ecosystem the application integrates with.
+
+ - Name:
foaf:name, with fallbacks to schema:name, vcard:fn, as:name, or rdfs:label. For structured names: schema:givenName+schema:familyName, foaf:givenName+foaf:familyName, or vcard:given-name+vcard:family-name.
+ - Short name / nickname:
foaf:nick, with fallback to vcard:nickname.
+ - Avatar / photo:
vcard:hasPhoto, with fallbacks to as:image, as:icon, foaf:img, schema:image, vcard:photo, sioc:avatar, or foaf:depiction.
+ - Email:
vcard:hasEmail, with fallbacks to schema:email or foaf:mbox.
+ - Telephone:
vcard:hasTelephone.
+ - Address:
vcard:hasAddress (with vcard:country-name, vcard:locality on the value).
+ - Description / bio:
vcard:note, with fallback to schema:description.
+ - Birthday:
vcard:bday.
+ - Organization & role:
vcard:organization-name and vcard:role; for richer involvement, org:organization/org:member and org:role, or schema:hasOccupation.
+ - Pronouns:
solid:preferredSubjectPronoun, solid:preferredObjectPronoun, solid:preferredRelativePronoun.
+ - Skills:
schema:skills, with fallback to cco:skill.
+ - Languages:
vcard:language, with fallbacks to schema:knowsLanguage or solid:preferredLanguage.
+ - Friends / contacts:
foaf:knows, with fallback to schema:knows.
+ - Profile colours:
solid:profileHighlightColor, solid:profileBackgroundColor.
+ - Homepage / web page:
foaf:homepage, foaf:weblog, schema:url, or vcard:url.
+ - Social accounts:
foaf:account, with account nodes carrying foaf:accountName and foaf:userProfilePrefix.
+
+
None of these are guaranteed to be present; UIs should fall back to the WebID URI when no human-readable label is available.
+
+
+
+
Note
+
Data discovery beyond the profile varies across the ecosystem. Mechanisms in active use include: Type Indexes; Solid Application Interoperability (SAI); SPARQL or Quad Pattern Fragments endpoints; fixed paths under the root of a storage; and DCAT catalogues. This guide does not prescribe a single mechanism.
+
+
+
References
@@ -477,6 +668,24 @@
References
[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
+
[WEBID]
+
WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
+
+
[WEBID-PROFILE]
+
Solid WebID Profile. Virginia Balseiro; Jeff Zucker; Sarven Capadisli (eds.). Tim Berners-Lee; Sarven Capadisli; Virginia Balseiro; Timea Turdean; Jeff Zucker (authors). W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solid.github.io/webid-profile/
+
+
[RDF11-CONCEPTS]
+
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
+
+
[FOAF]
+
FOAF Vocabulary Specification 0.99. Dan Brickley; Libby Miller. 14 January 2014. URL: http://xmlns.com/foaf/spec/
+
+
[VCARD-RDF]
+
vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Working Group Note. URL: https://www.w3.org/TR/vcard-rdf/
+
+
[SCHEMA-ORG]
+
Schema.org. W3C Schema.org Community Group. URL: https://schema.org/
+
[BKY+24]
AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting.
From 6ec3f4346043fe6025091af756b3bd7f50c3ec39 Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Fri, 24 Apr 2026 02:20:03 +0100
Subject: [PATCH 42/46] Trim ETag conditional-PUT section to a pointer
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Per @csarven (#776 thread on line 386): the full step-by-step flow
and the strong/weak ETag footnote were replaying RFC 9110 rather
than guiding. Collapse to one paragraph that states the problem,
names the mechanism, and points at W3C Editing the Web and
RFC 9110 § Validator Fields.
---
solid26.html | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/solid26.html b/solid26.html
index abf71a3f..cbd5a9f2 100644
--- a/solid26.html
+++ b/solid26.html
@@ -372,17 +372,7 @@ Solid Protocol
Clients might encounter Servers that do not support 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.
+ 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.
From 9bfe0bf8ced08038d97f87df97ad6ef3eed33168 Mon Sep 17 00:00:00 2001
From: Jesse Wright <63333554+jeswr@users.noreply.github.com>
Date: Fri, 24 Apr 2026 02:24:55 +0100
Subject: [PATCH 43/46] Fix malformed HTML in Solid Protocol comments
The third outer bullet had a
that was never closed before an
inner
(invalid: cannot contain block-level content), and a
trailing orphan
after the outer
. Close the paragraph
before the list and drop the orphan. Addresses @TallTed (#776
thread on line 372).
---
solid26.html | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/solid26.html b/solid26.html
index cbd5a9f2..ed5d2a17 100644
--- a/solid26.html
+++ b/solid26.html
@@ -410,14 +410,14 @@ Note
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)
-
+
+
+ - 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)
+
-
Table of Contents
3.1.1 Requirements derivable from Solid26 Implementation Guide specifications
3.1.2 Common assumptions not required by Solid26 Implementation Guide specifications
3.1.3 Assembling the Profile
- 3.1.4 Security Considerations