EventSourceChannel2023
Editor’s Draft, 2023-01-11
More details about this document
- This version
- https://solid.github.io/notifications/eventsource-channel-2023
- Latest version
- https://solid.github.io/notifications/eventsource-channel-2023
- Created
- Published
- Modified
- Repository
- GitHub
- Issues
- Language
- English
- License
- MIT License
- Document Status
- Editor’s Draft
- In Reply To
- Solid Origin
- Solid Notifications Protocol
- Notifications Panel Charter
- Policy
-
- Rule
- Offer
- Unique Identifier
- https://solid.github.io/notifications/eventsource-channel-2023#document-policy-offer
- Target
- https://solid.github.io/notifications/eventsource-channel-2023
- Permission
-
- Assigner
- W3C Solid Community Group
- Action
Copyright © 2023 W3C Solid Community Group.
Abstract
The Solid Notifications Protocol defines a set of interaction patterns for agents to establish subscriptions to resources.
This specification defines a channel type that applies these patterns to the EventSource 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 an Editor’s Draft. 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.
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 EventSource API 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 EventSource Web 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.
Terminology
This section is non-normative.
This document uses terminology from the Solid Notification Protocol, including subscription request
, discovery
. This document also uses terms from The OAuth 2.0 Authorization Framework specification, including resource server
, access token
, and client
.
Overview
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.
Conformance
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.
EventSourceChannel2023 Type
This specification defines the EventSourceChannel2023
type for use with Solid Notifications Protocol's subscriptions that use the EventSource Web API. The URI of the channel type is http://www.w3.org/ns/solid/notification#EventSourceChannel2023
.
An EventSourceChannel2023
API MUST conform to the Solid Notifications Protocol. [SOLID-NOTIFICATIONS]
A client establishes a subscription using the EventSourceChannel2023
type by sending an authenticated subscription request to the subscription resource based on Solid Notifications Protocol discovery.
For EventSourceChannel2023
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 EventSourceChannel2023
type. 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:
A successful response will contain a URL to the subscription API (receiveFrom
) that can be used directly with a JavaScript client.
In JavaScript, a client can use the data in the response to establish a connection to the EventSource hypermedia API.
A client will define how to handle events, especially the onerror
and onmessage
events.
References
Normative References
- [RFC2119]
- 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
- [RFC8274]
- 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]
- Solid Notifications Protocol. Sarven Capadisli. W3C Solid Community Group. Version 0.2.0. URL: https://solidproject.org/TR/notifications-protocol
- [SOLID-OIDC]
- SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. Version 0.1.0. URL: https://solidproject.org/TR/oidc
- [SOLID-PROTOCOL]
- Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo. W3C Solid Community Group. Version 0.10.0. URL: https://solidproject.org/TR/protocol