Solid is a set of specifications to describe a decentral Web protocol that enables Personal Data Spaces, empowering individuals to keep control of their personal data, stored in decentralized personal online data stores called Pods. Here, Verifiable Credentials (VC) are a type of data of particular interest, as they allow for cryptographically secure and verifiable digital credentials, which can be used for access and identity management, and also tie into diferent European Data strategy use cases. However, although the use of VCs within Solid is increasingly receiving attention, there exists no VC exchange protocol within Solid. More specifically, current applications need to rely on implicit agreements for both the transfer destination (i.e. the Web location where the VC should be sent to), and the data format of the messages exchanged. This forces stakeholders to invent their own credential transfer mechanisms, thereby hampering interoperability and adoption. In this paper, we present a VC exchange protocol between Solid Pods with explicit target destination and message format. We propose a working and interoperable protocol using DIDComm for structured messaging primitives in the form of JSON-headers and LDN inboxes as target destinations. LDN inboxes are interoperable with Solid and can be advertised via WebIDs, however, their setup and management of LDN inboxes is dificult, and reliance on WebIDs for inbox discovery might prevent interoperability between systems with diferent identifiers.
Opportunities for Personal Data Spaces (PDS) emergedue to ongoing efort on Data Spaces [
Of particular interest to PDS and Solid are Verifiable Credentials (VC) [
However, there exists no transfer protocol that specifies how to transfer VCs in the Solid ecosystem – from, to, and between Solid Pods – without relying on implicit applicationdependent agreements. VCs are thus transferred on case-by-case basis. This challenges interoperability and adoption, as new developers and users are prevented from adopting and re-using existing working solutions, and have to resort to out-of-band-communication or reading each others’ source code.
All the steps within a VC lifecyle –issuing, holding, and verifying– have been demonstrated
to work with Solid [
In this paper, we present a VC exchange protocol between Pods. We especially focus on (i) where and how should VCs be transferred between Solid Pods, and (ii) in which format. After introducing background and related work (Section 2), we specify our approach (Section 3) and implementation (Section 4), finally discussing (Section 5) and concluding on it (Section 6).
Solid – currently developed by the Solid W3C Community Group2 being formed into a W3C
Working Group – adopts the Linked Data Platform (LDP) specification 3, with each Solid Pod
containing its own collection of linked resources (e.g. images, CSV files, and RDF data). However,
as neither Solid nor LDP specify rules on where to write data, interoperability issues arise [
Verifiable Credentials (VCs) have been used and explored in combination with Solid in
multiple ways. VCs have been used in Solid for issuance, verification, authentication, and
authorization [
Communication in Solid is done via standard HTTP methods, with more detailed
notification and exchange protocols built on top. The Solid protocol itself specifies two notification
protocols: Linked Data Notifications (LDN) [
LDN is a W3C recommended permissive and decentralized push-based communication protocol6, intended for interoperability, and without restraints on possible usage domains. It
3https://www.w3.org/TR/ldp/ 4https://solid.github.io/webid-profile/ 5https://solidproject.org/TR/notifications-protocol 6https://www.w3.org/TR/ldn/ applies the Solid principles – deduplication of data storage and data usage – by treating and persisting notifications as resources. That means any received notification gets saved on the receiving server as a document, which allows notifications to be treated as unique entities, including assignment of a URI. Center to LDN is the LDN inbox, which acts as destination and receiving endpoint for all Linked Data notifications, in turn allowing further consumption. LDN does not specify any rules on message type or format. It also does not do any authentication, validation, or verification of messages. In Solid, the LDN inbox gets set via the public-facing WebID profile document 7, allowing its discovery.
The Solid Notification Protocol in comparison is a subscription based protocol, intended for receiving update notification on resource changes. It allows clients to listen to resource updates. Unlike LDN, which starts with the discovery of the inbox, a Solid Notification subscription begins with discovering notification services available on a resource. Then, a Subscription Request is sent, and a Notification Channel established. This notification channel can be of varying types, including WebSockets, WebHooks, and LDN8.
Out of these protocols, LDN is the most generic and modular, evidenced by its ample
extensions and adaptions, e.g. for Web Push Notifications [
The Trust over IP stack describes how to facilitate trust and exchange VCs between
peers on the Internet [
When transferring VCs between Solid Pods, current implementations’ interaction between multiple parties depends on implicit contracts and out-of-band communication for both the transfer destination (i.e., the location where the VC gets sent too) and the data structure.
Our solution design therefore consists of two components. On the one hand, by using a notiifcation protocol as a way to transfer data, we make the out-of-band agreements explicit. On the other hand, by adhering to a standardized message structure, we make sure that interoperability across applications is retained.
LDN solves the problem of out-of-band agreements on transfer destination via its inboxes. In Solid, LDN inboxes can be explicitly advertised via the WebID profile document. As the WebId profile document allows to make statements about the owner of a Solid Pod, we can associate a Solid user identity with the transfer destination by advertising the user’s inbox. This means that the minimum required information for a credential transfer is the WebID of the other party: as long as they have set up and advertised their inbox (by setting the ldp:inbox triple), notifications can be sent. The LDN inbox acts as receiver for all incoming notifications, handling them as individual entities with their own respective URIs.
Figure 1 shows an overview of our LDN inbox system. Neither the Sender nor the Consumer need to be using Solid, although the consumption of the inbox (Read, Write, Delete) likely is access controlled9.
As LDN depends on implicit data structures, interoperable consumption and reuse will be dificult. We therefore build on top of the DIDComm Messaging methodology.
We adapt the DIDComm plaintext message format to form a reusable envelope that wraps around the to-be-transported VC, with the intention of being easy to create, send, and consume on a Solid Pod, in turn enabling common VC ecosystem use-cases, e.g. issuance, holding, and verification. We do so by reusing and introducing a number of DIDComm notification JSON(-LD) headers to structure the notification. Table 1 shows the protocol headers, which can be divided into three categories: Improved inbox handling, data reuse, and data envelope.
By default, handling of the LDN inbox is dificult, as it contains an unstructured collection of resources, and inherently lacks means to identify and find notifications (e.g. notifications get saved with a random UUID as file name). To find a specific notification, inbox consumers need to access and read each notification one-by-one. We reuse DIDComm’s id, from, to, and created_time to help identify the notification in the inbox and provide inbox consumers with common hooks to look and query for, even though these consumers still need to access and scan each notification in the inbox. The optional expires_time can be used to enable automatic cleanup and deletion.
To make the data usable and understandable, we reuse the type header to specify the notification type of the credential enveloped in the body. The type should be descriptive, machine-understandable, actionable, and promote reuse, e.g. by using a shared RDF data vocabulary allowing an inbox consumer to understand how to consume it. For example, the type https://example.org/IPCEP/transfer could be used to indicate that this notification is being transferred, and can be consumed as is10.
The protocol has been implemented in a research prototype, available on GitHub at https://github. com/SolidLabResearch/inter-pod-credential-exchange-protocol, DOI https://doi.org/10.5281/ zenodo.10992060, under the permissive MIT License. It is built on top of the Community Solid Server, a Solid Pod reference implementation11. For the issuance, derivation, and verification of the credentials, we use the mature Mattr Linked Data proof suite to create BBS+ Signatures for the VC12.
Our demo mimics a common VC lifecycle in the Solid ecosystem. It is split into three phases:
2. The Holder consumes the VC, derives a new VC, and sends it to the Holder 3. The Verifier consumes and verifies the derived VC
For this, three Solid Pods (one for each actor) have been set up, each with a corresponding WebID and LDN inbox. Our proposed exchange protocol is used in the first and second phase to send credentials, and in the second and third phase to receive and consume credentials. The Holder is located in the middle of the flow, with the Issuer and the Verifier not knowing about each other. This is intended to showcase that the protocol is interoperable: sending a message from party A to party B, and then forwarding the same message from party B to party C, with C being able to read and understand it.
To cold-start the demo, we assume that the Issuer already knows the identity of the Holder (WebID), as it is necessary to issue a credential. Similarly, we assume the Holder knows the Verifier (WebID), as they present the claim to them.
Figure 2 shows the demo flow. 10Specification of actual type descriptions is out of scope of this paper. 11https://github.com/CommunitySolidServer/CommunitySolidServer 12https://github.com/mattrglobal/jsonld-signatures-bbs/ (a) Issuer issues and sends new VC (b) Holder derives and sends secondary VC
In Figure 2a, the Issuer issues and sends a new VC to the Holder. First, the Issuer issues a new VC (A). Then, the Issuer resolves the WebID of the Holder (1-2) to discover the location of the LDN inbox (3). The Issuer envelopes the VC, specifying the correct headers, and POSTs it to the inbox of the Holder (4). The Holder monitors their inbox for changes, by ways not determined in our protocol (B). To consume the inbox, the Holder GETs all notifications in the inbox (5), and then discovers and consumes them one-by-one (6). As each notification specifies a message type, the Holder can understand if a notification contains a VC, and knows how to unpack it (C).
In Figure 2b, the Holder derives and sends a secondary VC to the Verifier. The flow is identical to Figure 2a, except that the Holder derives a VC (D), which the Verifier verifies it in the end ( F).
LDN proves successful as transport mechanism, allowing us to send notifications from, to, and between Solid Pods. However, neither the setup of the inbox, nor the handling and consumption of it are straightforward.
On the one hand, setup of the inbox needs to be done manually, which involves adding the correct triple to the WebID profile document, as well as making sure that the inbox container exists, and that access control (i.e. being readable and writeable) is set. This manual setup is required as Solid Pod implementations, such as the Community Solid Server, do not set up an inbox by default13. This is done as safety measure and to combat spam, as a public LDN can be written to by everyone. Hence, our approach does not completely remove implicit agreements: an inbox needs to be (manually) set up.
Also, notifications get placed in one inbox container without any order , using a generated UUID as file name. There are no default means for filtering and finding resources. To ifnd a specific notification, we must loop through the whole (unpaginated) notification collection and inspect every message individually.
On the other hand, as the inbox constitutes a central container that stores an unstructured and unprotected collection of notifications, it will be accessed by diferent consumers applications that all share the same set of rights to move, change, read or delete notifications . This makes it possible for a negligent or malicious consumer to move or delete notifications that are otherwise being relied on. This can be partially mitigated with access controls, for example by restricting consumers to read-only, as well as preventing change and deletion of notifications, but usability and privacy concerns remain.
We can summarize above findings into following recommendations for LDN support in Solid: (i) provide an option to enable and disable an (LDN) inbox within pod management software, (ii) provide methods for filtering and pagination of notifications, and (iii) allow for more granular access and usage controls.
We now continue a more high-level discussion on functionality of our proposed approach.
As exchanges can take place across ecosystem boundaries, we do not allow addressing multiple recipients in the to header. Sending to multiple recipients should be done separately, as otherwise the WebID of every recipient will be disclosed.
To stay extensible and re-usable for a wide range of targeted purposes, we do not set any rules on how to consume the notification and contained credential . Instead, our protocol ofers the type header to specify how to consume the enveloped data, for example through use of semantic vocabularies.
Taking a step back, the LDN design depends on a properly set up inbox (which provides no failsafe except for HTTP error codes), and relies on WebIDs for discovery. Although WebIDs are the default identifier within Solid, they do not yet integrate well with other identifiers used in the the VC ecosystem, such as Decentralized Identifiers 14.
13https://github.com/CommunitySolidServer/CommunitySolidServer/issues/515 14https://www.w3.org/TR/did-core/
In this work, we designed an application-level inter-Pod credential exchange protocol and implemented it in a research prototype on top of the Community Solid Server. We apply LDN in combination with DIDComm Messaging primitives to solve the problem of implicit contracts when transferring VCs in the Solid ecosystem.
The combination of LDN and DIDComm Messaging were demonstrated succesfully, but we ifnd that LDN has weaknesses that hamper ease of use, especially filtering and finding notifications in the inbox. An LDN inbox intermediary could help manage the diferent notifications. Similarly, there is a need for more granular access control for messages, as well as usage policies and logs, to show how notifications are consumed and processed in the LDN inbox.
Looking at our transfer protocol, we currently use a plain-text message body. This sufices for our purposes, and also has the benefit of improved clarity and ease of debugging. Nevertheless, a next step should be secure encapsulation, e.g. encrypted and signed DIDComm Messaging envelopes, to help with verifiability, tamper-evidence, and provenance. Similarly, our protocol could be extended to interoperate with other DIDComm protocols, for example by supporting diferent identifiers to discover the LDN inbox.
Although being a first step in inter-Pod credential exchange, we believe our protocol has the
potential to solve a real need and can be extended to broader requirements, relevant for the
GDPR and the DGA [
The described research activities were supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10), and imec ICON project SHARCS (Agentschap Innoveren en Ondernemen project nr. HBC.2022.0543).