Version 1.0.0, 2022-05-09

More details about this document
This version
Latest version
Editor’s draft
Aaron Coburn
MIT License
Document Status
In Reply To
Solid Origin
Solid Notifications Protocol
Notifications Panel Charter
Unique Identifier
W3C Solid Community Group


The Solid Notifications Protocol defines a set of interaction patterns for agents to establish subscriptions to resources in a Solid Storage.

This specification defines a subscription type that applies these patterns to the WebSocket Web API.

Status of This Document

This section describes the status of this document at the time of its publication.

This document was published by the Solid Community Group as Version 1.0.0. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.

Publication as Version 1.0.0 does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.


This section is non-normative.

The Solid Notifications Protocol describes a general pattern by which agents can be notified when a Solid Resource changes. In the context of a Web Browser, the WebSocket API provides a convenient mechanism for a Solid Storage to alert a subscribing client of these changes.

This document describes a Solid Notifications subscription type that makes use of the WebSocket Web API.

This specification is for:


This section is non-normative.

This document uses terminology from the Solid Notification Protocol, including subscription API, gateway API. This document also uses terms from The OAuth 2.0 Authorization Framework specification, including resource server, authorization server, access token, and client, as well as terms from the WebSub specification, including topic.


This section is non-normative.

The following diagram shows the high-level interactions involved in this flow. How a client retrieves an access token for step 5 is outside the scope of this document.

Solid WebSocketSubscription2021 Flow


All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

The key words “MUST” and “MUST NOT” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

WebSocketSubscription2021 Type

This specification defines the WebSocketSubscription2021 type for use with Solid Notifications subscriptions that use the WebSocket Web API. The URI of the subscription type is http://www.w3.org/ns/solid/notification#WebSocketSubscription2021.

An WebSocketSubscription2021 API MUST conform to the Solid Notifications Protocol. [SOLID-NOTIFICATIONS]

An WebSocketSubscription2021 API SHOULD support the Solid Notifications Features.

The WebSocketSubscription2021 type defines the following properties:

The source property is used in the body of the subscription response. The value of this property MUST be a URI, using the wss scheme. A JavaScript client would use the entire value as input to the WebSocket constructor.

A client establishes a subscription using the WebSocketSubscription2021 type by sending an authenticated subscription request to the hypermedia API retrieved via Solid Notifications discovery.

For WebSocketSubscription2021 interactions, the client sends a JSON-LD payload to the appropriate hypermedia API via POST. The only required fields in this interaction are type and topic. The type field MUST contain the type of subscription being requested. The topic field MUST contain the URL of the resource a client wishes to subscribe to changes.

Subscription Example

This section is non-normative.

An example POST request using a DPoP bound access token is below:

Example: Requesting an WebSocket subscription URL from the Notification Subscription.

POST /subscription
Authorization: DPoP <token>
DPoP: <proof>
Content-Type: application/ld+json

  "@context": ["https://www.w3.org/ns/solid/notification/v1"],
  "type": "WebSocketSubscription2021",
  "topic": "https://storage.example/resource",
  "state": "opaque-state",
  "expiration": "2021-12-23T12:37:15Z",
  "rate": "PT10s"
POST request including type and topic targeting the Notification Subscription API.

A successful response will contain a URL to the subscription API that can be used directly with a JavaScript client.

Example: Response from the Notification Subscription including the WebSocket subscription URL.

Content-Type: application/ld+json

  "@context": "https://www.w3.org/ns/solid/notification/v1",
  "type": "WebSocketSubscription2021",
  "source": "https://websocket.example/?auth=Ys3KiUq"
Response to the POST request including type and source.

In JavaScript, a client can use the data in the response to establish a connection to the WebSocket hypermedia API.

Example: Establishing a new WebSocket connection.

const ws = new WebSocket(source, type);
JavaScript code to establish a new WebSocket connection

A client will define how to handle events, especially the onclose and onmessage events.

Example: Handling WebSocket events after the connection is established.

ws.onclose(evt => reconnect(evt));
ws.onmessage(evt => console.log("Message received: ", evt))
JavaScript code to handle onclose and onmessage events

Authentication and Authorization

As described by the Solid Notifications Protocol section on Authorization, the WebSocket subscription API requires authorization and follows the guidance of the Solid Protocol sections on Authentication and Authorization [SOLID-PROTOCOL].

It is beyond the scope of this document to describe how a client fetches an access token. Solid-OIDC is one example of an authentication mechanism that could be used with Solid Notifications [SOLID-OIDC].


Normative References

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
Solid Notifications. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. Version 0.1.0. URL: https://solidproject.org/TR/notifications-protocol
SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor's Draft. URL: https://solid.github.io/solid-oidc/
Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol