Repository navigation
[wg/lws] Linked Web Storage Working Group Charter #566
Description
New charter proposal, reviewers please take note.
Charter Review
Expected end of charter refinement phase: 2026-10-15
What kind of charter is this? Check the relevant box / remove irrelevant branches.
- Existing WG recharter
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. Also add a "card" for this issue to the Strategy Funnel.
Substantive changes
None. The initial charter was aggressively optimistic. The WG hopes to get to CR Q4-2026 or Q1-2027, then switch to maintenance mode.
(this still needs to be clarified in the charter text, which is currently just the output of the charter assistant)
Communities suggested for outreach
See https://w3c.github.io/lws-wg-charter/#coordination
Known or potential areas of concern
None
Activity
acoburn commentedon Aug 4, 2026
The LDP Next and WebID Community Groups have both closed since the last chartering. Should they be removed from this charter?
I would also suggest a weekly WG meeting cadence (rather than bi-weekly)
Remove "LDP Next" from coordination
tidoust commentedon Aug 19, 2026
@pchampin, ok to initiate the charter refinement phase. You'll need to request a short extension for the current charter as well. Please combine both announcements.
xueyuanjia commentedon Sep 7, 2026
2026-09-07: Start of refinement for a draft Linked Web Storage Working Group charter; current charter extended
simoneonofri commentedon Sep 9, 2026
In my review of the previous charter, I suggested developing an LWS Threat Model with a structured RFC 3552 analysis, and examined the existing Security Considerations through STRIDE. I am glad to see that this work is now available in the LWS repository.
Could the Group restore the LWS Threat Model under Other Deliverables as a non-normative Group Note, using the current work as its starting point, and continue developing it during this charter period?
plehegar commentedon Sep 15, 2026
Charter refinement
matatk commentedon Sep 23, 2026
No concerns from APA
pchampin commentedon Sep 24, 2026
@simone, thanks for the suggestion, this has been done in w3c/lws-wg-charter#4
himorin commentedon Sep 25, 2026
No comment nor request from i18n.
csarven commentedon Oct 8, 2026
Thank you for requesting the TAG's review. This review is based on the proposed charter as of 2026-10-08.
The TAG's biggest concern is that this work is unlikely to result in an interoperable standard: it invents a new protocol that is not compatible with prior work, and the proposed success criteria no longer verify that implementations interoperate with each other. The review below notes this and related concerns, and we recommend they be addressed before re-chartering.
The TAG also notes that the initial charter commits the group to seeking the TAG's review at each major standards-track transition. However, those invitations have not yet reached us.
Although this review is limited to the charter, the group remains welcome to bring charter changes as well as the deliverables to the TAG for review, while the architectural design can still be steered.
On Interoperability
The initial and the proposed charter's Scope promises "interoperability between compliant user applications, and compliant storage and identity servers". However, the proposed charter removes "independent implementations interoperating with each other" from the success criteria, leaving that promise unverified. Conformance to a test suite alone does not show that different classes of products work with one another.
Examples from a cursory reading:
Each of these permits conforming, test-passing deployments that do not interoperate. In each case, interoperability is deferred to another layer or placed out of scope; no deliverable ensures the end-to-end interoperability between user applications and servers that the Scope promises.
The TAG is concerned that these decisions will fragment the very ecosystem the group is trying to establish.
The TAG recommends that the group either work towards meeting its interoperability commitments, with the verification that backs them (as in the initial charter), or drop the claims and be explicit about the limits of what is being offered. Without a common baseline, optional mechanisms are a limit on interoperability, not flexibility. A mandatory-to-implement baseline would not restrict that flexibility; it is a floor any two implementations can meet, with room for more above it. Reliable interoperability is the commitment the group made to the web in its motivation and background.
The charter also draws its motivation from the Solid CG's incubation of interoperability, while the deliverables are compatible with none of the prior work: not the Solid Protocol CG Draft, not the Fedora API, not even the Linked Data Platform (LDP) Recommendation. Taking justification from an ecosystem while chartering deliverables incompatible with it fragments that ecosystem. Nothing so far indicates the deliverables offer something better in the terms the Scope itself sets.
On Deliverables and Scope
The review request calls the initial charter "aggressively optimistic". The optimism of that charter at least rested on a head start: incubated input documents to build from, and implementation experience to draw from. The proposed charter keeps a comparable scope while giving up that head start, since the deliverables depart from those inputs into new design. Two years in, with most documents barely past FPWD, the proposed charter appears to be the more optimistic version.
The TAG's concern is not the number of specifications; a modular set of small documents can be the right structure. The concern is the breadth: the chartered deliverables span storage, identity and authentication, authorization, access management, discovery, and notifications in a single effort. New design of this breadth matures best in a CG or an equivalent incubation phase.
The deliverables are also unevenly factored: authentication is split into three suites, while the rest is folded into the single core specification. The TAG encourages structuring the deliverables following the principle of orthogonal specifications ( https://www.w3.org/TR/webarch/#orthogonal-specs ).
Architecturally, where specifications already exist, it would be preferable for the WG to bring its use cases and requirements to the groups responsible for them, to avoid duplication and fragmentation.
As chartered, the result is one more linked data protocol beside LDP, the Solid Protocol, and the Fedora API. The TAG has not seen an explanation of why a new protocol is needed rather than one that builds on existing specifications in this problem space.
Input documents are a starting point rather than a boundary: the deliverables already build on specifications well beyond them, just not on the prior work nearest their scope. The Use Cases and Requirements work would establish which requirements the existing specifications cannot meet, and how that was determined. That analysis is most useful when it comes before the design.
On Data Formats
Both charters place "definition of new data formats" out of scope, yet the drafts define
application/lws+jsonandapplication/lws+cid. A new media type is how the web names a new data format ( https://www.w3.org/TR/design-principles/#new-data-formats , https://www.w3.org/TR/webarch/#formats ). Reusing a top-level type does not make it the same format. Two subtypes can be completely different in meaning and interpretation.Either these media types are new data formats and the deliverables fall outside the chartered scope, or the group should state the reading of the exclusion under which they are not, since the drafts were developed under it.
The drafts seem to indicate that the same content can be served with existing media types. This does not change what was defined, only whether it was needed. Under an exclusion on new data formats, defining types that existing ones could cover is the harder position to justify.
The TAG appreciates the work the group has taken on, looks forward to the revised charter, and welcomes review requests for the deliverables.
acoburn commentedon Oct 14, 2026
Thank you to the TAG for this careful review. We agree with much of it, and we plan the charter and specification changes described below. A few points need clarification, and we want to explain our reasoning on those.
Design review and timeline. The TAG is right that we have not yet asked it to review the deliverables. We will open a design review for LWS Core and the authentication suites, with an explainer. We will also move the CR milestones later, so that the WG can finish the documents while giving the TAG and other horizontal reviewers enough time before CR.
Success criteria. Dropping "two or more implementations interoperating with each other" comes from a change in the W3C charter template. It seems that this text was considered inappropriate for some classes of W3C recommendations, but we agree that it still makes sense for Linked Web Storage. We will add it back.
Interoperability. The TAG's review lists six examples where conforming implementations might not interoperate. One concerns authorization, where LWS already has a mandatory baseline: OAuth 2.0. Every storage server MUST accept JWT access tokens (RFC 9068), MUST identify its authorization server in the
WWW-Authenticatechallenge of a 401 response, and MUST validate tokens against the authorization server's published keys. Every authorization server MUST support OAuth 2.0 Token Exchange (RFC 8693), which turns a credential from any supported authentication suite into such an access token. As a result, clients and storage servers from different implementers interoperate through the same OAuth 2.0 flow, whichever authentication suite is used.LWS uses the OAuth 2.0 roles unchanged, with the storage server as the resource server. OAuth 2.0 itself places any protocol-defined interaction between the authorization server and the resource server out of scope (RFC 6749 §1.1), so on its own it does not say what an access token contains or how a resource server should validate one, leaving that to profiles and extensions (§1.8). LWS is one such profile: it defines the token format and required claims, as well as how storage servers validate tokens. Because each storage server names its authorization server in its 401 challenge, clients need no prior configuration to reach it.
Two other examples in the TAG's review are, in our opinion, narrower than they look. On trust, both the SSI-CID and OpenID suites define in-band issuer discovery when there is no prior trust relationship between the verifier and the credential issuer. On conformance, LWS servers and clients are already defined as HTTP servers and clients bound by the HTTP requirements in the Operations section.
In each of these cases, we agree that the specification text can be clearer, and we will improve it before we ask for a design review.
The remaining three examples are fair, and we will propose the following changes:
Relationship to prior work. The TAG is right that this is not included in the charter proposal. When we request a design review, there will be an explainer to cover LDP, the Solid Protocol and the Fedora API, and for each difference (containment, access control, metadata, identity) it will give the WG's rationale. In the meantime, we will also update the charter's Background section to summarize this relationship.
Scope. We understand the TAG's concern about breadth. Rather than returning to a CG, we would prefer to narrow the scope. The FPWDs are published, their exclusion periods have ended, and the WG has a test suite and multiple server implementations. For storage, there is no active group that could take on this work, since the LDP WG and the related CGs have closed. Where specifications already exist, we have reused them (OAuth, OpenID Connect, CID, ODRL) instead of inventing new mechanisms. We are open to making Index Services and Webhook Notifications tentative deliverables or Notes, and we would welcome the TAG's view on that.
On structure, we agree with the TAG that the question is how the deliverables are factored, not how many there are. The WG has weighed many small documents against fewer consolidated ones, and so far has kept shared models in Core, with authentication suites and notification channels as separate specifications that build on it. We will revisit this with the principle of orthogonal specifications in mind, starting with whether the authorization profile and access requests should move out of Core.
Data formats. The TAG makes a good point that new media types, strictly speaking, can be seen as new data formats. We believe however that the WG followed the spirit of the charter, as those media types are in fact simply profiles of JSON-LD. The storage description is already a conforming controlled identifier document, so we will propose using
application/cidand droppingapplication/lws+cid. Forapplication/lws+json, the WG wants to provide a clear way to distinguish this profile from other JSON-LD representations, as it provides a smoother migration path from other protocols such as LDP or Solid). The WG considered several options, includingapplication/ld+jsonwith aprofileparameter. The WG asked the JSON-LD WG for advice on this very question (minutes, 2026-01-28) and adoptedapplication/lws+jsonon that advice (LWS minutes, 2026-02-16). A major factor was that profile URIs contain CORS-unsafe request-header bytes. The JSON-LD WG's advice was that profile parameters with URI values are not a good fit for browser-facing protocols (see w3c/json-ld-syntax#436). We would welcome the TAG's view on whether it agrees. Either way, we will clarify the charter's exclusion so that vocabularies, profiles and the media types that name them are clearly in scope.We will update the charter draft to reflect the changes above. We will also track the specification changes as issues in w3c/lws-protocol and include them in our design review request.