Narrative Goldmine

Solid

38 min read

Properties

Type
  • Class
Resource
  • urn:ngm:class:solid
Domain
  • infrastructure
Status
  • stable
Maturity
  • established
Quality
  • 0.52
Is a
Has part
Requires
Enables
Generated
  • by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Bridges to
Contrasts with
Depends on
Implemented in layer
Implements
Legacy term id
  • IF-0801
Links
Page resource
  • urn:visionflow:page:38d5c68c9d15d1a600a3df3b4128e5ca0e614e4286ffb60fdb5104e3cac377e5
Related to
Standardized by
Supports
Uses

Solid (Social Linked Data) is an open-source, W3C-specification-grounded decentralised web architecture conceived by Sir Tim Berners-Lee at MIT CSAIL (Massachusetts Institute of Technology Computer Science and Artificial Intelligence Laboratory) commercialised through the startup Inrupt and steer…

Semantic Classification

Content

Compositional Relationships (Components)

SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:Pod))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:WebID))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:SolidOIDC))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:WebAccessControl))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:LinkedDataPlatform))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:RDFDataModel))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:AccessControlPolicy))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:hasPart prot:SolidProtocolSpecification))

## Dependency Relationships
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:RDF))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:HTTP))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:WebID))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:TurtleSyntax))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:JSONLD))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:SPARQL))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:requires prot:OpenIDConnect))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:dependsOn prot:W3CStandards))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:dependsOn prot:SemanticWebStack))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:dependsOn prot:RESTArchitecture))

## Capability Relationships
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:DataPortability))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:DataSovereignty))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:ConsentManagement))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:CrossApplicationInteroperability))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:PrivacyByDesign))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:enables prot:DecentralizedIdentity))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:supports prot:GDPRCompliance))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:supports prot:HealthDataManagement))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:supports prot:GovernmentOpenData))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:supports prot:PersonalDataManagement))

## Implementation Relationships
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:implements prot:LinkedDataPlatformSpec))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:implements prot:WebAccessControlSpec))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:implements prot:AccessControlPolicySpec))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:implements prot:SolidOIDCSpec))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:implements prot:WebIDProfileSpec))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:uses prot:TurtleSyntax))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:uses prot:JSONLD))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:uses prot:SPARQLEndpoint))

## Reduction Relationships
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:reduces prot:DataSiloing))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:reduces prot:VendorLockIn))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:reduces prot:ConsentFriction))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:reduces prot:PrivacyViolationRisk))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:reduces prot:DataDuplicationCost))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:relatedTo prot:DecentralizedIdentifiers))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:relatedTo prot:VerifiableCredentials))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:relatedTo prot:ActivityPub))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:contrastsWith prot:CentralizedDataSilo))
SubClassOf(prot:Solid
  ObjectSomeValuesFrom(prot:contrastsWith prot:OAuthDataSharing))

## Data Properties
DataPropertyAssertion(prot:hasIdentifier prot:Solid "IF-0801"^^xsd:string)
DataPropertyAssertion(prot:authorityScore prot:Solid "0.87"^^xsd:decimal)
DataPropertyAssertion(prot:specVersion prot:Solid "0.11.0"^^xsd:string)
DataPropertyAssertion(prot:foundedYear prot:Solid "2015"^^xsd:integer)
DataPropertyAssertion(prot:commercialisedYear prot:Solid "2018"^^xsd:integer)
DataPropertyAssertion(prot:stewardOrg prot:Solid "Open Data Institute"^^xsd:string)

## Annotations
AnnotationAssertion(rdfs:label prot:Solid "Solid (Social Linked Data)"@en)
AnnotationAssertion(rdfs:comment prot:Solid "Decentralised web protocol invented by Tim Berners-Lee at MIT CSAIL (2015), commercialised by Inrupt (2018), and steered by the Open Data Institute (October 2024). Provides user-controlled Pod storage, WebID identity, Solid-OIDC authentication, and WAC/ACP access control on top of RDF/Linked Data. Deployed by Flemish Government (Athumi data utility, 2023), NHS Greater Manchester, NatWest Bank, BBC, and governments in Sweden, Argentina and Basque Country; formal W3C Linked Web Storage Working Group chartered September 2024."@en)
AnnotationAssertion(dcterms:identifier prot:Solid "IF-0801"^^xsd:string)
AnnotationAssertion(dcterms:subject prot:Solid "Decentralised Web, Linked Data, Data Sovereignty, Personal Data Pods, Semantic Web"@en)

)

Property Characteristics

AsymmetricObjectProperty(prot:requires) AsymmetricObjectProperty(prot:enables) AsymmetricObjectProperty(prot:implements) AsymmetricObjectProperty(prot:reduces) TransitiveObjectProperty(prot:dependsOn) FunctionalDataProperty(prot:authorityScore) FunctionalDataProperty(prot:specVersion)

About Solid

  • Solid (Social Linked Data) represents the most ambitious attempt since the invention of the Web to restructure the foundational data architecture of the internet. Where the first-generation web (Web 1.0) made information readable, the second generation (Web 2.0) made it writable and participatory, the third generation—which Solid embodies—aims to make it decentralised and user-sovereign. The core insight is architectural rather than merely technical: the problem with the modern web is not that platforms are malicious, but that their business models structurally require them to aggregate, retain, and monetise user data as a condition of service provision. Solid breaks this coupling by separating the data layer from the application layer. Users maintain data in Pods; applications request access. An application that loses a user’s trust can be revoked without the user losing their data. When a user migrates from one social network, healthcare app, or financial service to another, they carry their history with them in their Pod rather than abandoning it in a defunct account.
  • The project began as academic work at MIT CSAIL under Tim Berners-Lee’s group, building on fifteen years of Semantic Web research. The Semantic Web vision—originally articulated in Berners-Lee, Hendler, and Lassila’s 2001 Scientific American article “The Semantic Web”—posited a web where data would be machine-readable and interlinked through shared ontologies, enabling intelligent agents to traverse and reason over distributed knowledge graphs. Solid operationalises this vision at the personal data layer: instead of a read-only graph of public web pages, Solid creates a read-write graph of personal, institutional, and governmental data, with access control governing what agents (human users, applications, AI systems) can read or write. The initial SoLiD paper (Mansour et al., 2016) articulated the Pod-application separation and WebID-based identity model, drawing on earlier DIG work: WebID-TLS (an earlier authentication mechanism using client certificates, now superseded by Solid-OIDC), LDP (which DIG contributed to the W3C standardisation process), and FOAF (Friend of a Friend ontology by Dan Brickley and Libby Miller, 2000, providing the social graph vocabulary).
  • Inrupt was founded in 2018 to commercialise the technology and establish the Enterprise Solid Server (ESS) as a production-grade infrastructure layer. By 2020, Inrupt had signed its first major institutional partners—including the BBC, NatWest Bank, and the NHS—using ESS as the enterprise backbone. In parallel, academic and open-source development continued through the Community Solid Server (CSS), led by researchers at imec-IDLab and Ghent University’s WISE research group, with a landmark paper by Van Herwegen and Verborgh (2024) characterising CSS’s role as a modular research platform for the evolving Solid ecosystem. The governance of Solid underwent a significant transition in October 2024 when the Open Data Institute assumed stewardship of the Solid Project. The ODI brought Solid’s community governance, specification processes, and ecosystem development into its broader data stewardship activities, creating a more neutral, foundation-style body to oversee the protocol’s evolution distinct from Inrupt’s commercial interests. Monthly “Solid World” events (continuing through 2025, archived on the ODI website) serve as the primary community synchronisation mechanism.

Technical Core: The Four-Layer Architecture

Layer 1 — Identity: WebID

  • WebID is a URI-based identity mechanism enabling globally unique, self-sovereign identification across the distributed web. A WebID is an HTTP URI (e.g., https://alice.solidpod.net/profile/card#me) that dereferences to an RDF document (the WebID Profile) containing machine-readable claims about the entity: name, email, FOAF relationships, Pod storage locations (expressed using ldp:inbox and pim:storage predicates), public key materials for authentication (using the CERT vocabulary), and type information (foaf:Person, schema:Person). WebID fundamentally differs from centralised identity providers (OAuth via Google/Facebook/GitHub) in that identity resolution requires only an HTTP request to the user’s own URI—no third-party identity broker is involved. If Alice’s WebID is https://alice.solidpod.net/profile/card#me, any Solid server can verify her identity by fetching that URI and validating the cryptographic claims, without contacting a central registry. The WebID Profile specification (W3C Solid Community Group) defines mandatory predicates (rdf:type foaf:Document, foaf:primaryTopic, solid:oidcIssuer) and recommended predicates (name, storage, inbox). WebID also enables institutional identities: organisations, government agencies, and AI agents can each have WebIDs that establish their identity in the Solid ecosystem.

Layer 2 — Authentication: Solid-OIDC

  • Solid-OIDC is the authentication layer extending standard OIDC (RFC 6749/6750, OpenID Connect Core 1.0) for decentralised scenarios where the resource server does not know the identity provider in advance. In centralised OAuth, when you log in with Google, the resource server trusts Google’s token because it has been pre-registered with Google’s OAuth infrastructure. In Solid, users may choose any Solid-compatible OIDC Provider—their Pod provider, their employer’s IdP, or a dedicated identity service—and the resource server must be able to validate tokens from arbitrary issuers it has never pre-configured. Solid-OIDC solves this through DPoP (Demonstration of Proof-of-Possession, RFC 9449) tokens: short-lived (typically 15-minute TTL), cryptographically-bound access tokens where each token is tied to a specific client key pair, preventing token replay attacks across different resource servers. The authentication flow proceeds: (1) user authenticates to their chosen Solid OIDC Provider (can be any Solid-compatible IdP); (2) receives an ID Token containing a webid claim pointing to their WebID URI; (3) presents a DPoP-bound access token to the resource server (Pod); (4) resource server resolves the WebID to verify identity claims (checking solid:oidcIssuer to confirm the token issuer is authorised); (5) resource server evaluates WAC/ACP rules to determine permitted operations. Specification version 0.1.0 published by W3C Solid Community Group (March 2022), authored by Aaron Coburn, elf Pavlik, and Dmitri Zagidulin. The DPoP binding ensures that even if an access token is intercepted, it cannot be replayed by an attacker without possession of the associated private key.

Layer 3 — Storage: Linked Data Platform

  • LDP (Linked Data Platform), a W3C Recommendation (2015), provides the RESTful API layer underpinning Pod resource management. LDP defines a hierarchy of container types: BasicContainer (a simple directory-like container), DirectContainer (a container whose membership is automatically maintained by the server), and IndirectContainer (a container using an intermediary resource to represent membership). Resources within containers are either RDF Sources (documents containing RDF triples—Turtle, JSON-LD, N-Triples, N-Quads) or Non-RDF Sources (binary files: images, PDFs, audio, video). Standard HTTP operations: GET (retrieve resource or container listing), PUT (replace resource), POST (create new resource within container), PATCH (partial update via SPARQL-update or N3-patch), DELETE (remove resource), HEAD (retrieve metadata headers). Solid extends base LDP with: Solid-specific HTTP headers (Solid-Type for resource typing), WAC .acl resource conventions, Solid Notifications Protocol (WebSocket and webhook subscriptions to resource change events), and PATCH support for N3 patches (using solid:InsertDeletePatch for atomic triple-level modifications). The LDP container model maps naturally onto filesystem-like hierarchies—/profile/, /health/, /finance/, /social/—making Pods intuitive for developers familiar with REST APIs while maintaining semantic interoperability through RDF metadata headers.

Layer 4 — Access Control: WAC and ACP

  • Web Access Control (WAC) is the primary authorisation mechanism specified in the Solid Protocol (version 1.0.0, May 2024, edited by Sarven Capadisli). WAC operates through ACL (Access Control List) resources—RDF documents stored at .acl extension URIs that specify which WebIDs or FOAF groups have which access modes over which resources. Access modes are expressed using the acl: vocabulary: acl:Read (GET/HEAD requests), acl:Write (PUT/DELETE/PATCH requests), acl:Append (POST to add content without overwriting), acl:Control (read and modify the ACL resource itself—equivalent to “owner” permission). WAC supports inheritance through acl:default triples: a container’s ACL applies to all contained resources unless a more specific ACL is found by traversing up the containment hierarchy. Authorization subjects can be individual WebID URIs, FOAF Groups (RDF documents listing multiple WebIDs), foaf:Agent (everyone, public access), or acl:AuthenticatedAgent (any authenticated Solid user). WAC’s limitation is its flat, per-resource ACL model: it cannot express conditional policies (purpose-limited access, time-bounded grants, context-sensitive rules) natively.
  • Access Control Policy (ACP) is a more expressive authorisation framework developed to address WAC’s limitations, particularly for GDPR purpose-limitation and temporal constraints. ACP introduces Policy resources written in a dedicated policy language using the acp: vocabulary, allowing access matchers to specify conditions: a Matcher can require specific WebID membership, specific OIDC issuer, specific client application, or custom claim values. Access Rules combine Matchers with access modes; Policies aggregate Rules. This enables statements like “Grant Read access only to WebIDs in the medical-research-group, only when the requesting client claims purpose=clinical-research, only before 2027-01-01”—enforcing GDPR purpose limitation at the protocol level. ACP and WAC are both permitted by the Solid Protocol specification; servers MUST support at least one. A 2024 community proposal (Solid specification GitHub issue #787) recommended making WAC the required baseline (MUST) and ACP optional (MAY), acknowledging WAC’s wider deployment while preserving ACP for complex governance scenarios. Inrupt ESS and Flemish government deployments implement ACP for regulatory compliance.

Components and Architecture

  • Pod (Personal Online Data Store): The fundamental storage unit of the Solid ecosystem. A Pod is an LDP-compliant hierarchical container system that stores resources at dereferenceable HTTP URIs. Pod contents are typically organised into semantic namespaces: /profile/ (WebID and public profile), /private/ (encrypted or restricted data), /public/ (publicly accessible documents), /health/ (medical records with healthcare-provider ACLs), /finance/ (banking data with financial-service ACLs), /social/ (social graph and communications with friend-group ACLs), /credentials/ (Shape-Tree-validated professional credentials). Pods can be self-hosted on any LDP-compliant server, hosted by commercial Pod providers (Inrupt’s ESS, SolidWeb.org running NSS 5.7.8 with 3,032 accounts, solidcommunity.net), or deployed institutionally. The Pod URI namespace is user-controlled; migration between Pod providers is a defined operation in the Solid Protocol, preserving data without identity loss because the user’s WebID URI remains the stable identifier while the pim:storage predicate in the WebID Profile is updated to point to the new Pod location.
  • Community Solid Server (CSS): The primary open-source reference implementation, maintained at github.com/CommunitySolidServer/CommunitySolidServer (imec-IDLab, Ghent University). CSS is built with Node.js and Components.js—a dependency injection framework that allows CSS’s internal components (authentication handler, ACL evaluator, storage backend, notification publisher) to be wired together via JSON configuration files, enabling research variants without code changes. A CSS instance can be configured to use in-memory storage (for testing), filesystem storage, or SPARQL-backed storage. The CSS paper (Van Herwegen and Verborgh, 2024, Semantic Web journal) characterises CSS as explicitly designed to support research and development in an evolving ecosystem, contrasting with production-optimised servers. CSS version 6.x and 7.x support WAC, ACP (experimental), the Solid Notifications Protocol, and Shape Trees validation. CSS instances include solidweb.me (v6.1.0, 504 accounts) and various institutional deployments.
  • Node Solid Server (NSS): The original Solid server implementation, begun in 2014 as an early Node.js prototype. NSS is now deprecated in favour of CSS but remains in operation at solidweb.org (NSS 5.7.8, 3,032 accounts). NSS includes the Mashlib/Solid-OS databrowser as a built-in interface for Pod management, which CSS omits in favour of configurable external interfaces. Migration guides from NSS to CSS are available from the Solid Community Forum.
  • Inrupt Enterprise Solid Server (ESS): The commercial-grade implementation offering production scalability, LDAP/Active Directory integration, enterprise SSO, SLA support, compliance reporting, and advanced monitoring. ESS underpins all major governmental and enterprise deployments: Flemish Government/Athumi, NHS pilots, NatWest, BBC, and government contracts in Sweden, Argentina, Basque Country. The July 2024 Data Wallet product—a React Native mobile application connecting to ESS’s Wallet API—enables end-user management of Pod data, consent grants, and data sharing, targeted at consumer-facing deployment scenarios.
  • Solid-OS / Mashlib: A browser-based application suite providing a graphical interface for managing Pod contents, composing linked-data applications, and visualising RDF knowledge graphs. Solid-OS provides drag-and-drop file management, address book management (via vCard/FOAF), calendar integration, and read-write access to any Solid resource the user has permissions for. It serves as the demonstration application for Solid’s cross-application interoperability: data created in the address book component of Solid-OS can be read by any other Solid application that understands the vCard ontology.
  • Comunica: A modular SPARQL engine (JavaScript/TypeScript, developed at Ghent University by Ruben Verborgh’s group) that serves as the primary query engine for Solid applications. Comunica implements Link Traversal Query Processing (LTQP)—the ability to answer SPARQL queries by following RDF links across multiple Pods rather than querying a centralised endpoint. A LTQP query can traverse from Alice’s WebID Profile to her social graph (FOAF links), then follow each friend’s WebID to their calendar (using ical: ontology), answering “show all events from my friends’ calendars” by traversing potentially dozens of Pods. Performance challenges with LTQP at scale (latency multiplied by each HTTP hop) are a primary focus of ongoing Solid research.

Use Cases and Major Deployment Families

Government Data Portals

  • The Flemish Government (Belgium) represents the most advanced governmental Solid deployment globally. In spring 2023, Athumi was established—Europe’s first data utility company—to manage the secure exchange of citizens’ data across government organisations and businesses under the Solid protocol. Athumi functions as a trusted third-party data intermediary: it operates Pod infrastructure for Flemish citizens, brokers consent-governed data flows between governmental agencies and private-sector organisations, and provides a governance framework for data access that satisfies EU data protection regulations. The initial “My Professional Data MVP” launched in 2023, allowing citizens to store professional credentials (diplomas, professional certifications, permits) in their government-issued Pods and share them with employers or services on demand—eliminating paper-based certificate presentation and reducing administrative friction. Microsoft adapted its Entra identity technology to work with Solid-OIDC authentication, enabling Flemish businesses to authenticate Solid access grants using their existing Microsoft identity infrastructure. A full government data integration platform—connecting environmental permits, social welfare entitlements, building records, and business licences—is scheduled for 2026, which would make Flanders the first region in the world where Solid Pods are the standard mechanism for citizen-government data exchange. Additional Inrupt government contracts span Sweden (national digital identity integration), Argentina (social services data portability), and the Basque Country, Spain (regional government citizen services), with pilots running in Singapore, Japan, and Helsinki.

Healthcare Data Sovereignty

  • The NHS Greater Manchester pilot represents the most concrete UK healthcare Solid deployment, predating the current enrichment window. The pilot investigated Solid Pods for dementia patient care pathways, allowing patients and carers to store, control, and share health records across NHS Trust boundaries without records being locked in a single Trust’s system. The Greater Manchester LHCRE (Local Health and Care Record Exemplar) programme provided the institutional framework, targeting an initial MVP with under 5,000 Pods to validate the concept. The patient-controlled Pod model addresses a structural fragmentation problem in UK healthcare: patient records are distributed across GP practices (EMIS/SystmOne), acute hospital trusts (various EPR systems), community care providers, and social care organisations, none of which interoperate natively. A patient’s Solid Pod could aggregate authorised extracts from all these systems into a coherent personal health record, with granular ACLs controlling which provider sees which data. Broader NHS interest aligns with the NHS Long-Term Plan for interoperable health records and UK GDPR consent-management requirements. Australia’s healthcare system also features in Inrupt’s deployment portfolio, and healthcare applications were cited among Inrupt’s 2024 partnership case studies.

Financial Services

  • NatWest Bank engaged with Inrupt’s Data Wallet at SIBOS 2024, publishing analysis of how Solid-based data wallets could reshape financial services consent management, Know Your Customer (KYC) data sharing, and financial data portability under PSD2 and UK GDPR. The analysis identifies a core use case: instead of a bank maintaining a separate copy of a customer’s identity documents, income history, and credit data, the customer stores these in their Pod and grants the bank time-limited, purpose-specific read access for a loan application. After the application decision, the access grant expires and the bank cannot retain the data beyond the stated purpose—satisfying GDPR data minimisation and storage limitation principles automatically through Pod architecture. Inrupt’s Data Wallet implements a React-Native mobile application connecting to the ESS Wallet API, enabling users to store financial credentials, purchasing history, professional credentials, demographic data, and subscription/membership information in their Pod. Data sharing events are cryptographically consent-coupled: each access grant is a signed, time-stamped, purpose-annotated record stored in the user’s Pod alongside the data it governs, providing an auditable consent trail for regulatory compliance.

Media and Publishing

  • The BBC participated in early Inrupt ESS pilots exploring Solid-based user preference and subscription management. The vision: BBC account preferences (viewing history, content preferences, parental controls, accessibility settings, subscription status) are stored in the user’s own Pod rather than in BBC’s centralised database. BBC applications are granted read (and write-back) access to these Pod resources. This architecture enables data portability across competing broadcasters: a user migrating from BBC iPlayer to Channel 4 or ITV could grant the new service read access to their existing preferences Pod, allowing the new service to personalise immediately rather than starting cold—operationalising GDPR Article 20 data portability rights in a technically enforceable way. The model also enables cross-service personalisation: a user whose health Pod indicates dietary restrictions could grant a BBC Food recipe app read access to relevant health data to personalise recipe recommendations, with full control over what the app can see and for how long.

Research Data Management and FAIR Principles

  • Solid aligns naturally with the FAIR data principles (Findable, Accessible, Interoperable, Reusable, Wilkinson et al. 2016), which provide a framework for scientific data stewardship increasingly mandated by research funders including Horizon Europe, UKRI, and the Wellcome Trust. A researcher’s Pod can serve as a personal FAIR data repository: datasets are stored at stable, dereferenceable URIs (Findable), accessible via standard HTTP with Solid-OIDC authentication (Accessible), described using domain ontologies (Interoperable), and licensed with explicit reuse permissions expressed in ACL resources (Reusable). SPARQL federation across institutional Pod deployments enables cross-institution query without centralising data: a federated LTQP query can traverse participant Pods across multiple universities to aggregate clinical trial data without the data ever leaving participants’ institutional Pods. The SolidLab Flanders research consortium (VUB/imec, Belgium) and Ghent University’s WISE group produce the primary academic output on Solid’s research data management applications.

Decentralised Social Applications

  • Solid’s original motivation was reshaping social media by decentralising data from platforms like Facebook and Twitter. LDP Inboxes (defined in the LDP Notifications specification) provide a standardised notification mechanism: an LDP Inbox is an LDP Container at a known URI (typically </inbox/>) where any authorised agent can POST a notification message (using the ActivityStreams 2.0 or custom RDF vocabularies). Social interactions—follows, friend requests, messages, event invitations, article reactions—can flow between different Solid Pod providers via these Inboxes, analogous to email across different mail servers. This creates a federated social graph where users choose their own Pod provider but can interact with users on any other provider—similar to ActivityPub (the W3C Recommendation underpinning Mastodon and the Fediverse) but with richer data sovereignty semantics: WAC/ACP governs exactly who can read the social graph, whereas ActivityPub’s security model is coarser-grained. Solid Lite—referenced in the original stub—is a proposed simplified profile of the Solid protocol targeting lower-resource environments and simpler use cases, potentially addressing the developer adoption barrier posed by the full Solid stack.

Academic Context

  • Solid emerged from MIT CSAIL’s Decentralised Information Group (DIG), where Tim Berners-Lee’s research programme had for over a decade pursued the vision of the Read-Write Web and Semantic Web. The foundational paper “Solid: A Platform for Decentralized Social Applications Based on Linked Data” (Mansour et al., 2016) articulated the core architectural vision, drawing on: (1) WebID-TLS (earlier authentication via client certificates, developed by Manu Sporny, Melvin Carvalho, and others, superseded by Solid-OIDC); (2) LDP (Linked Data Platform, W3C Recommendation 2015, DIG contribution); (3) FOAF (Friend of a Friend ontology, Dan Brickley and Libby Miller 2000, providing social graph vocabulary); (4) Linked Data Notifications (W3C Recommendation 2017, Capadisli et al., providing the LDP Inbox mechanism). The broader academic ecosystem spans multiple research communities: the Semantic Web and Linked Data community (ISWC, ESWC conferences; Semantic Web journal) provides the RDF/OWL/SPARQL substrate; the Web Science community (Web Science conference, Southampton University’s Web Science Institute) studies web architecture and governance; the privacy engineering community (IEEE S&P, USENIX Security, ACM CCS) contributes threat modelling for decentralised identity and access control; the human-computer interaction community (CHI, CSCW) studies user comprehension of Pod-based consent interfaces—a persistent challenge, as multiple studies show users struggle to reason about fine-grained ACL policies without more intuitive visual representations.
  • Notable academic contributions to the Solid ecosystem: Ruben Verborgh (Ghent University/imec-IDLab) on LTQP, Comunica, and the Linked Data Fragments research programme; Sarven Capadisli (specification editor, WAC v1.0.0, Solid Protocol 0.11.0); Kjetil Kjernsmo (specification editor, Solid Protocol 0.11.0); Justin Bingham (Solid Application Interoperability specification and Shape Trees); Wouter Termont (ACP specification); Joachim Van Herwegen (CSS architecture, 2024 Semantic Web journal paper); Angelo Di Iorio and colleagues on Solid and scholarly communication. The SolidLab Flanders consortium (VUB/imec, funded by the Flemish Government) is the largest single academic investment in Solid research globally, producing contributions to CSS development, governance frameworks, use-case validation, and ontology development for governmental data exchange. The Ethical Web and Data Architecture (EWADA) programme at Oxford University’s Internet Institute (OII) published analysis of the ODI-Solid collaboration (October 2024), framing Solid within ethical web architecture principles. The W3C Linked Web Storage Working Group (chartered September 2024) brings together academic researchers (Ghent, MIT) and industry contributors (Inrupt, community representatives) to produce formal W3C Recommendations.

Current Landscape (2026)

  • As of 2026, Solid occupies an important but contested position in the decentralised web ecosystem. On the specification side, the LWS WG is expected to publish formal W3C Recommendations for the core Solid protocol stack by 2026-2027, resolving long-standing tensions in the community: the WAC vs ACP baseline question (2024 proposal to make WAC the required MUST and ACP optional MAY), the Solid Notifications Protocol finalisation (WebSocket, webhook, and Server-Sent Events variants), and Shape Trees/ShEx integration for data-model-level interoperability beyond API-level protocol compliance. Shape Trees—hierarchical templates specifying how data should be organised in Pods using ShEx (Shape Expressions) or SHACL constraints—are the key enabler for the “any app, any data” interoperability vision: when a healthcare app stores a Patient resource conforming to a standardised Shape Tree, a second app from a different vendor can discover and parse that data without bespoke integration.
  • On the commercial side, Inrupt expanded its enterprise platform with the July 2024 Data Wallet product, operationalising personal data portability for government and financial services clients. The Data Wallet enables users to store identity credentials, professional certifications, demographic data, event tickets, purchasing histories, and dietary preferences in their Pod and share specific subsets through granular, revocable access grants—a practical embodiment of GDPR rights to data portability (Article 20) and erasure (Article 17, as revoking an access grant prevents future data access even if the application cached the data). Inrupt’s enterprise contracts now span multiple continents.
  • The ODI stewardship transition introduced foundation-style governance: technical steering committees, contribution guidelines, Solid World monthly events, and a community-first roadmap process. Key adoption challenges as of 2026: (1) Consumer adoption velocity: despite high-profile pilots, consumer-facing Solid Pod adoption remains low compared to centralised alternatives like Google Drive or Dropbox; (2) Developer experience: building Solid applications requires fluency in RDF, SPARQL, and decentralised authentication—a steep learning curve versus REST/JSON APIs; developer tooling (Solid.js React hooks, Tripledoc, RDFlib.js) has improved but RDF fluency remains a barrier; (3) Query federation performance: LTQP over distributed Pods remains orders of magnitude slower than centralised database queries due to HTTP request overhead per triple-pattern; (4) Trust and consent UI: users struggle to reason about fine-grained ACL policies without intuitive visual access management interfaces; (5) Ecosystem fragmentation: multiple competing application interoperability proposals (SAI, Type Indexes, Shape Trees) have not yet converged on a single standard, slowing cross-application data sharing despite API-level Solid compliance.
  • Competitive landscape: ActivityPub (W3C Recommendation 2018, basis of Mastodon/Fediverse) provides federated social networking without Pod-style data sovereignty; Decentralised Identifiers (DIDs, W3C Recommendation 2022) and Verifiable Credentials (VCs, W3C Recommendation 2022) provide identity and credential portability compatible with Solid’s WebID model; IPFS provides content-addressed decentralised storage without the semantic RDF layer or fine-grained access control; AT Protocol (Bluesky’s protocol) provides federated social media with user-controlled Personal Data Servers (PDS) analogous to Pods. The emerging community consensus positions these as complementary rather than competing: DIDs/VCs for verifiable identity credentials, Solid/LWS for arbitrary data sovereignty, ActivityPub for social graph federation.

UK Context

  • The United Kingdom has notable Solid research and deployment activity across academic and industrial sectors. The Open Data Institute (ODI, London), co-founded by Sir Tim Berners-Lee and Sir Nigel Shadbolt in 2012, assumed stewardship of the Solid Project in October 2024, making London the global governance hub for the protocol. The ODI’s Solid stewardship aligns with UK government digital strategy priorities around open data, GDPR compliance, and citizen-controlled personal data—positioning Solid as a key technology for the UK’s smart data agenda and the Data (Use and Access) Act 2025.
  • The NHS Greater Manchester pilot represents the most concrete UK healthcare Solid deployment, targeting dementia patient care pathways within the Greater Manchester LHCRE (Local Health and Care Record Exemplar) programme. The pilot investigated how Pods could support care coordination across primary, secondary, and social care providers without centralised data warehouses, targeting an MVP with under 5,000 Pods. Alignment with the NHS Long-Term Plan for interoperable records and the NHS’s 10-Year Health Plan (2025) for AI and data transformation creates continued institutional appetite for Solid-based healthcare data infrastructure in England.
  • NatWest Bank (Edinburgh-headquartered, one of the UK’s largest retail and commercial banks) engaged with Inrupt’s Data Wallet at SIBOS 2024, publishing analysis of Solid-based consent management for financial services. NatWest’s public engagement—as a FTSE 100 institution with millions of UK retail customers—represents significant potential for UK financial sector adoption, particularly under PSD2/PSD3 open banking mandates and UK GDPR portability rights.
  • The BBC (London, Broadcasting House) participated in early ESS pilots exploring Solid-based user preference management for BBC iPlayer, BBC Sounds, and BBC News applications. As a public broadcaster with statutory duties around data stewardship and millions of UK users, the BBC’s interest in Solid reflects alignment between public service broadcasting values and user data sovereignty principles. The BBC’s data ethics framework (published annually) explicitly references user data control as a strategic priority.
  • Academic activity spans multiple UK institutions. The Knowledge Media Institute (KMi) at the Open University (Milton Keynes) has longstanding expertise in Semantic Web, knowledge representation, and linked data—areas foundational to Solid. KMi’s CORE (COnnecting REpositories) project for open access research aggregation uses Linked Data principles aligned with Solid’s data model, and KMi researchers participate in Semantic Web conference communities where Solid research is presented. The University of Southampton Web Science Institute (founded with Berners-Lee’s co-founding involvement via the Web Science Trust) conducts web architecture research directly relevant to Solid’s decentralised design philosophy. Imperial College London’s Data Science Institute engages with data governance frameworks that Solid could underpin, particularly in healthcare and smart city contexts. The University of Manchester and University of Leeds are engaged in health informatics and open data initiatives that intersect with the NHS Solid pilot’s North West England context.
  • Solid intersects with UK regulatory context through multiple frameworks: the Data (Use and Access) Act 2025 (DUA Act) establishes smart data schemes—sectoral frameworks for consent-driven data portability—precisely matching Solid’s architectural capabilities; UK GDPR Article 20 (data portability right) gives individuals the right to receive their data in a structured, machine-readable format and transmit it to other controllers—operationalised architecturally by Solid Pods; the UK National Data Strategy (2020, refreshed 2021) and National Health Service Data Strategy both emphasise interoperability and patient-controlled data; Inrupt’s UK presence through the Inrupt-ODI partnership provides commercial and governance support for UK deployments.

Future Directions (2026-2030)

W3C Linked Web Storage Recommendations (2026-2027)

  • The LWS WG, chartered September 2024, is expected to publish formal W3C Recommendations for the core Solid protocol stack by 2026-2027. These formal Recommendations will supersede the Community Group Draft reports and provide the legal and procurement clarity required by governments and regulated industries requiring standards-body endorsement as a condition of adoption. The Working Group’s scope covers the storage protocol (LDP extensions), authentication (Solid-OIDC and DPoP), notifications (WebSocket and webhook variants), and access control (WAC baseline, ACP optional). Formal Recommendation status is expected to significantly accelerate public-sector adoption in EU member states (where ENISA and national CERTs typically require W3C or ISO standards for critical infrastructure procurement) and in UK government digital service frameworks.

Shape Trees and Application Interoperability (2026-2027)

  • Shape Trees (combining ShEx or SHACL constraints with LDP container hierarchy templates) will enable application interoperability at the data-model level—not merely API-level Solid compliance. When a healthcare application stores a Patient resource conforming to a standardised Shape Tree (mapping to HL7 FHIR R4 SMART-on-FHIR profiles, expressed in ShEx), a second application from a different vendor can discover that resource by following the Shape Tree index in the Pod and parse it without bespoke integration code. The Solid Application Interoperability (SAI) specification (Justin Bingham et al.) defines authorisation agent patterns: a user appoints an authorisation agent (a trusted service or application) to manage access grants on their behalf, with fine-grained access to specific Shape Trees rather than entire Pod subtrees. SAI and Shape Trees together form the interoperability layer that transforms Solid from “apps can share a Pod” to “apps can understand each other’s data.”

AI Agent Integration and Agentic Solid (2027-2030)

  • The rise of agentic AI systems creates compelling Solid use cases. An AI assistant (personal agent, healthcare planning agent, financial planning agent) authorised to read specific Pod resources on behalf of a user could personalise responses using rich, user-controlled personal data—health history, dietary preferences, professional background, financial constraints, calendar data—without that data permanently residing in the AI provider’s training corpus or inference database. This “agentic Solid” pattern aligns with EU AI Act requirements for data minimisation and purpose limitation in AI systems: the AI agent receives only the Pod data it has an explicit access grant for, cannot retain data beyond the grant’s expiry, and the user can audit all AI data access through the Pod’s consent trail. The Solid Application Interoperability’s authorisation agent model provides the technical infrastructure for fine-grained AI agent scoping. As agentic frameworks (LangChain, AutoGPT, Claude computer-use, Anthropic MCP) mature, Solid Pods may emerge as the canonical personal data store for AI agents operating in personal and enterprise contexts—replacing today’s pattern of AI assistants scraping user data from siloed applications through OAuth integrations.

Flemish Full Platform and EU Regulatory Alignment (2026)

  • Athumi’s full government data integration platform is scheduled for 2026, connecting environmental permits, social welfare entitlements, professional certifications, building records, and business licences across Flemish governmental agencies through a unified Solid Pod infrastructure. Success in Flanders—the first region in the world where Solid Pods are the standard mechanism for citizen-government data exchange—would provide a replicable model for other European regions and nations pursuing digital sovereignty under the EU Data Governance Act (DGA), Data Act, and AI Act. The DGA (applicable from September 2023) and Data Act (applicable from September 2025) together create a regulatory demand for exactly the consent-driven, auditable, user-controlled data sharing architecture that Solid provides, potentially positioning Solid as a compliance mechanism for these regulations rather than merely a research project.

Performance and Scalability Research (2026-2030)

  • Addressing LTQP performance over distributed Pods is a primary research challenge. Current approaches under investigation: materialised view caching (precomputing query results from frequently accessed Pod subsets with staleness tolerance), federated SPARQL endpoint indexes (Pod providers publishing SPARQL endpoints over their hosted Pods, enabling query planning to route to endpoints rather than traversing raw Pod HTTP), Comunica extensions for Pod-native query optimisation (link prioritisation heuristics, pruning policies for LTQP traversal), and shape-aware query planning (using Shape Trees to predict where relevant data resides without exhaustive traversal). The Solid Protocol’s Linked Data Notifications mechanism (WebSockets and webhooks) enables reactive architectures where applications subscribe to Pod change events and update materialised views incrementally, reducing query latency for frequently-accessed social or health data.

Limitations, Critiques, and Adoption Barriers

  • Solid has attracted substantive critical analysis alongside its advocacy. Leigh Dodds (ODI alumnus, data publishing practitioner) published “Confused by Solid” (March 2024) articulating a widely-shared practitioner critique: the Solid ecosystem suffers from specification fragmentation and instability. Multiple overlapping specifications—WAC vs ACP, different notification protocol variants, competing application interoperability proposals (Type Indexes vs SAI vs Shape Trees)—make it difficult for developers to make confident long-term implementation choices. The specification has evolved substantially since 2018, with breaking changes requiring updates to all conformant implementations. This instability imposes a hidden tax on adoption: developers who invested in NSS-era WAC implementations needed rework when CSS introduced ACP; developers building apps against one version of the Type Index specification found incompatibilities with later variants.
  • A second cluster of critiques concerns developer experience and ecosystem maturity. RDF’s steep learning curve—requiring familiarity with triple stores, SPARQL, Turtle syntax, ontologies, and JSON-LD framing—is a significant adoption barrier compared to the REST/JSON developer experience that dominates modern web and mobile development. Solid’s client-side JavaScript libraries (Solid.js, Tripledoc, RDFlib.js, Comunica) have improved substantially but remain more complex than typical REST client libraries. The lack of a dominant Solid application framework analogous to Rails or Django for web, or SwiftUI for iOS, means developers must assemble components from multiple libraries. This creates a high minimum viable expertise threshold that limits Solid development to specialists.
  • Performance is a third challenge. Link Traversal Query Processing (LTQP)—Solid’s mechanism for answering queries that span multiple Pods—requires one HTTP request per Pod traversal hop. A social query aggregating data from 100 friends’ Pods might require 100-500 sequential or parallel HTTP requests, with round-trip latencies accumulating to seconds or minutes versus milliseconds for a centralised SQL query. While materialised caching and query optimisation research (ongoing at Ghent University via Comunica) can mitigate this, the fundamental physics of distributed HTTP remain more expensive than local relational query at scale.
  • User comprehension of access control presents both a usability and security challenge. Research from the CHI and CSCW communities documents that non-expert users struggle to reason about fine-grained ACL policies: which application has access to which part of their Pod, for how long, for what purpose. Without intuitive visual interfaces (analogous to iOS permission prompts but for arbitrary resource hierarchies), users tend to grant over-broad access rather than carefully scoped permissions—replicating the privacy problems Solid aims to solve. The Solid Application Interoperability (SAI) specification partially addresses this by introducing authorisation agents that abstract ACL complexity, but these add another architectural layer.
  • Governance and commercial tension was a structural concern that the ODI stewardship transition was designed to address. With Inrupt as both the primary commercial implementer and the primary specification contributor, there were concerns in the community about whether the protocol would evolve to serve Inrupt’s enterprise clients rather than the open ecosystem. The ODI’s neutral stewardship from October 2024 separates specification governance from commercial implementation, analogous to the W3C’s governance of web standards—but the transition is recent and its long-term effectiveness remains to be demonstrated.

Developer Tooling Ecosystem

  • The Solid development ecosystem provides libraries and tools across multiple languages and frameworks. Solid.js (not to be confused with the SolidJS JavaScript UI framework) provides React hooks and utility functions for reading/writing Pod resources and managing access grants, targeting browser-based Solid application development. Tripledoc is a simplified RDF document library abstracting Triple-level operations into document-level API patterns, reducing the RDF expertise barrier for web developers. RDFlib.js provides full RDF/SPARQL capabilities for sophisticated linked-data applications. @inrupt/solid-client (Inrupt’s official TypeScript/JavaScript SDK) provides a high-level API for Solid Pod operations, authentication, and access grant management, targeting both browser and Node.js environments. Comunica (TypeScript, modular SPARQL engine) is used for LTQP and federated query across Pods; it supports multiple query execution strategies and source types, enabling custom query planning for Solid-specific access patterns.
  • For authentication, @inrupt/solid-client-authn-browser and @inrupt/solid-client-authn-node provide Solid-OIDC and DPoP token management. solid-oidc-provider is a reference OpenID Connect Provider implementation compliant with Solid-OIDC, enabling organisations to deploy their own Solid-compatible identity provider. For server deployment, Community Solid Server (CSS) can be installed via npm (npm install @solid/community-server) and configured through JSON configuration files for different backend storage options. Solid Dev Tools provides browser extension capabilities for inspecting Pod contents, ACL resources, and authentication tokens during development. SHACL/ShEx validators (shex.js, Validates.js) enable testing of Pod data conformance to Shape Tree constraints.
  • Testing infrastructure includes the Solid Test Suite (solid-contrib/web-access-control-tests on GitHub) which provides automated conformance tests for WAC implementation correctness, and the Solid Conformance Test Harness for broader protocol compliance testing across CSS, ESS, and other implementations. The ecosystem also includes Pod management UIs: Penny (a simple Pod browser for exploring LDP containers and RDF resources), Mashlib/Solid-OS (the full-featured integrated application suite), and Inrupt’s Pod Spaces (a production-ready Pod management interface for enterprise deployments).

Research and Literature

  • The Solid research literature spans semantic web, privacy engineering, human-computer interaction, and systems architecture. Key foundational works: Berners-Lee (2009) “Linked Data Design Issues” established the four linked data principles underpinning Solid’s data model; Berners-Lee, Hendler, Lassila (2001) “The Semantic Web” (Scientific American) articulated the vision of machine-readable interlinked web data; Mansour et al. (2016) “Solid: A Platform for Decentralized Social Applications Based on Linked Data” (WWW 2016) introduced the core architectural vision; Verborgh et al. (2016) “Triple Pattern Fragments” established efficient RDF federation techniques applicable to multi-Pod SPARQL; Capadisli et al. (2017) “Linked Data Notifications” (W3C Recommendation) provided the LDP Inbox mechanism foundational to social applications. For implementation and ecosystem: Van Herwegen and Verborgh (2024, Semantic Web journal, doi:10.3233/SW-243726) characterises CSS’s modular research platform architecture; Capadisli et al. (2024) “Solid Protocol 0.11.0” (W3C Draft Community Group Report, May 2024) is the current specification reference; Coburn, Pavlik, Zagidulin (2022) “Solid OIDC v0.1.0” provides the authentication specification; Capadisli (2024) “Web Access Control v1.0.0” provides the access control specification. For governance and deployment: ODI (2024) “ODI and Solid: Building a Future Where Data Works for Everyone” articulates the stewardship rationale; EWADA/OII Oxford (2024) frames Solid in ethical web architecture; Vlerick Business School analysis of Athumi as a data utility company model; NatWest SIBOS 2024 analysis of financial services data wallet implications. For access control: Solid specification GitHub issue #787 (2024) documents the WAC/ACP baseline debate with community discussion on implementation requirements. For developer ecosystem: Community Solid Server documentation (v7.x) covers ACP experimental implementation, authorisation methods, and configuration. UK regulatory context: UK GDPR Article 20 (data portability right); Data (Use and Access) Act 2025 (smart data schemes); NHS Long-Term Plan for interoperable records; Open Data Institute Annual Report 2024 “Advancing Trust in Data” covering Solid stewardship activities and ecosystem development priorities.

Ontological Relationships and Semantic Web Context

  • Solid’s position in the semantic web ontological landscape is defined by its dual nature as both a protocol stack (specifying HTTP-level operations, authentication flows, and access control mechanisms) and a data model (mandating RDF as the foundational representation, enabling OWL reasoning and SPARQL querying over Pod contents). This duality distinguishes Solid from purely protocol-level decentralised systems (IPFS, BitTorrent) that provide decentralised storage without semantic structure, and from purely semantic systems (DBpedia, Wikidata) that provide rich knowledge graphs without user-controlled access.
  • In the W3C standards landscape, Solid sits above the transport layer (HTTP/1.1, HTTP/2, HTTP/3), above the data model layer (RDF 1.1, OWL 2, SPARQL 1.1), and alongside the identity layer (WebID, DID, OIDC). It complements rather than replaces: RDF provides the data model, OWL provides ontological reasoning over Pod contents, SPARQL provides query, WebID provides identity, OIDC provides authentication, WAC/ACP provide authorisation—Solid’s contribution is the Pod resource management layer and the integration specifications binding these into a coherent decentralised data ecosystem. The Linked Data Principles (use URIs as names for things; use HTTP URIs so they can be looked up; when someone looks up a URI provide useful information using standards; include links to other URIs so agents can discover more things) are not merely design aesthetic in Solid: they are architectural requirements. Pod resources MUST be addressable by dereferenceable HTTP URIs; resource descriptions MUST use RDF; applications MUST follow RDF links to discover related data. This link-following architecture—Link Traversal Query Processing (LTQP)—enables distributed queries that span multiple Pods without a centralised index, at the cost of query latency measured in HTTP round trips rather than database operations.
  • The relationship between Solid and Decentralised Identifiers (DIDs, W3C Recommendation 2022) is complementary and convergent. DIDs provide globally unique, cryptographically verifiable identifiers that do not depend on any centralised registry—analogous to WebID but with additional cryptographic guarantees (DID Documents stored on distributed ledgers or other VDRs can prove control without HTTP dereference). The W3C Credentials Community Group has explored DID-to-WebID bridges, enabling Solid authentication using DID-based credentials. Verifiable Credentials (VCs, W3C Recommendation 2022) provide a JSON-LD-serialised, cryptographically-signed attestation format directly compatible with Solid’s RDF data model—VCs can be stored in Pods and shared via access grants, enabling a user to store their university degree, professional certification, vaccination record, or identity credential in their Pod and share a VC-formatted proof with a relying party on demand. The convergence of Solid + DIDs + VCs creates a comprehensive self-sovereign identity and data stack where the user controls both their identity (via DID/WebID) and their data (via Pod).

Metadata

  • domain-correction: infrastructure → protocol (Solid is a web protocol/standard rather than infrastructure tooling; IRI updated from infrastructure#Solid to protocol#Solid; URI namespace updated from infrastructure:solid to protocol:solid; owl-class updated accordingly; iri/uri/same-as corrected in frontmatter)

Provenance

Graph View

Backlinks