Solid StreamingHTTPSubscription2021

1. Introduction

This section is non-normative.

The [Solid.Notifications] describes a general pattern by which agents can be notified when a Solid Resource changes. In the context of a Web Browser, the Streaming HTTP 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 Fetch API.

This specification is for:

• Resource server developers who wish to enable clients to listen for updates to particular resources.

• Application developers who wish to implement a client to listen for updates to particular resources.

1.1. Terminology

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".

2. StreamingHTTPSubscription2021 Type

This specification defines the StreamingHTTPSubscription2021 type for use with Solid Notifications subscriptions. that use the Fetch API.

An StreamingHTTPSubscription2021 API MUST conform to the Solid Notifications Protocol.

An StreamingHTTPSubscription2021 API SHOULD support the Solid Notifications Features.

The StreamingHTTPSubscription2021 type defines the following properties:

source

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

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

For StreamingHTTPSubscription2021 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.

2.1. Subscription Example

This section is non-normative.

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

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

{
  "@context": ["https://www.w3.org/ns/solid/notification/v1"],
  "type": "StreamingHTTPSubscription2021",
  "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.

Content-Type: application/ld+json

{
  "@context": "https://www.w3.org/ns/solid/notification/v1",
  "type": "StreamingHTTPSubscription2021",
  "source": "https://fetch.example/?auth=Ys3KiUq"
}

Response to the POST request, including subscription type and the notifications source.

In JavaScript, a client can use the data in the response to establish a connection to the Fetch API. And define how to handle notifications

const response = await fetch('https://fetch.example/?auth=Ys3KiUq')
const textStream = response.body.pipeThrough(new TextDecoderStream());
for await (const notificationText of textStream) {
  parseAndHandle(notificationText)
}

3. Authentication and Authorization

Streaming HTTP Subscription has the advantage of being able to authenticate with the Subscription API as well as the notifications source. The same access token can be used with both resources. This doesn’t just rely on the notifications source being a Capability URL as many other subscriptions types do.

As described by the Solid Notifications Protocol section on Authorization, the Streaming HTTP 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].