Solid StreamingHTTPChannel2023

Editor’s Draft,

More details about this document
This version:
https://solid.github.io/notifications/streaming-http-channel-2023
Issue Tracking:
GitHub
Editor:
elf Pavlik

Abstract

The [Solid.Notifications.Protocol] defines a set of interaction patterns for agents to receive notification about changes to resources in a Solid Storage.

This specification defines a channel type that applies these patterns to the Fetch API.

Status of this document

Version: 0.1

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

This document was published by the Solid Community Group as an Editor’s Draft. 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 an Editor’s Draft 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.

1. Introduction

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 Streaming HTTP Channel provides a convenient mechanism for a Solid Storage to alert a subscribing client of these changes.

This document describes a Solid Notifications channel type that makes use of the Fetch API.

This specification is for:

1.1. Terminology

This section is non-normative.

This specification uses terms from the [Solid.Notifications.Protocol] specification. When Solid Notifications Protocol terminology is used it is linked directly to that specification.

2. StreamingHTTPChannel2023 Type

This specification defines the StreamingHTTPChannel2023 type for use with Solid Notifications channels. that use the Fetch API.

An StreamingHTTPChannel2023 MUST conform to the Solid Notifications Protocol.

An StreamingHTTPChannel2023 SHOULD support the Solid Notifications Features.

The StreamingHTTPChannel2023 type further constrains following properties properties:

receiveFrom

The receiveFrom property is used in the body of the subscription response. The value of source property MUST be a URI, using the https scheme.

A client establishes a subscription using the StreamingHTTPChannel2023 type by sending an authenticated subscription request to the Subscription Resource retrieved via Solid Notifications discovery.

For StreamingHTTPChannel2023 interactions, the client sends a JSON-LD payload to the appropriate Subscription Resource via POST. The only required fields in this interaction are type and topic. The type field MUST contain the type of channel being requested: StreamingHTTPChannel2023 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": "StreamingHTTPChannel2023",
  "topic": "https://storage.example/resource",
  "state": "opaque-state",
  "endAt": "2023-12-23T12:37:15Z",
  "rate": "PT10s"
}

POST request including type and topic targeting the Notification Subscription Resource.

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

Content-Type: application/ld+json
{
  "@context": "https://www.w3.org/ns/solid/notification/v1",
  "type": "StreamingHTTPChannel2023",
  "receiveFrom": "https://fetch.example/aca3cb0a-fb0a-4091-b9f8-8117d2cdb392"
}

Response to the POST request, including channel type and the receiveFrom URL.

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/aca3cb0a-fb0a-4091-b9f8-8117d2cdb392')
const textStream = response.body.pipeThrough(new TextDecoderStream());
for await (const notificationText of textStream) {
  parseAndHandle(notificationText)
}
solid/notifications/46Specify that each chunk must include one full notification.

3. Authentication and Authorization

Streaming HTTP Channel has the advantage of being able to authenticate with the Subscription Resource as well as the notifications receiveFrom. 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 channel types do.

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

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[Solid.Notifications.Protocol]
Aaron Coburn; et al. Solid Notifications Protocol. URL: https://solidproject.org/TR/notifications-protocol
[Solid.OIDC]
Aaron Coburn; elf Pavlik; Dmitri Zagidulin. Solid-OIDC. URL: https://solidproject.org/TR/oidc
[Solid.Protocol]
Sarven Capadisli; et al. Solid Protocol. URL: https://solidproject.org/TR/protocol