Solid WebPushChannel2023

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.

This document describes a Solid Notifications subscription type that makes use of the Push API for Web Push notifications in Progressive Web Applications (PWAs).

This specification is for:

• Resource server developers who wish to enable clients, i.e., PWAs, to listen for updates to particular resources.

• Application developers who wish to implement a client, i.e., a PWA, to listen for updates to particular resources.

1.1. Terminology

This section is non-normative.

Note: Let the predicate topic be an rdfs:subClassOf of as:object?

This document uses terms from the following specifications, as listed:

• from the [SOLID-NOTIFICATIONS] protocol, terms including "Notification Subscription Service"

• from the [PUSH-API] specification, terms including "push endpoint", "push service", and "authentication secret"

• from the [OAUTH-2.0] specification, terms including "authorization server" and "access token"

• from the [WEBARCH] specification, terms including "information resource"

This document additionally uses the following terms, as defined below:

browser messaging service

Refers to the implementation of a "push service" [PUSH-API] in a browser.

1.2. Overview

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

• Discovery: The discovery client discovers from the storage metadata a suitable subscription service. It further discovers from the subscription service's representation the vapidPublicKey of the subscription service.
• Establish Subscription: The subscription client subscribes to the browser messaging service to receive Web Push notifications using the vapidPublicKey of the subscription service. In return, the subscription client retrieves the endpoint, auth and p256dh values. A corresponding notification channel is requested from the Notification Service API. The subscription service authenticates the subscriber with the Authorization Server, checks the authorization of the subscriber and creates the notification channel.
• Deliver Notifications: The notification sender issues Push notifications to the browser messaging service which in turn delivers the Push notification to the notification receiver. For each notification, the subscription service checks the authorization of the subscriber with the Authorization Server.
  solid/notifications/185Changing access policy for a topic resource may require invalidating some channels
• Unsubscribe: When the subscriber chooses not to receive Web Push notifications anymore, it unsubscribes from the browser messaging service. Additionally, it sends an unsubscription request to the subscription service.
  solid/notifications/145Define unsubscribing

2. WebPushChannel2023 Type

This specification defines the WebPushChannel2023 type for use with Solid Notifications. The URI of the subscription type is <http://www.w3.org/ns/solid/notification#WebPushChannel2023>.

A WebPushChannel2023 MUST conform to the Solid Notifications Protocol.

A WebPushChannel2023 SHOULD support the Solid Notifications Features.

Note: Let the class WebPushChannel2023 be an rdfs:subClassOf of as:Follow?

The WebPushChannel2023 type defines the following properties:

vapidPublicKey

The vapidPublicKey property indicates the notification server’s public key as defined by [RFC8292], which can be used by the client for the Voluntary Application Server Identification (VAPID).

sendTo

The sendTo property indicates the "Push Endpoint" as defined in the [PUSH-API] specification.

keys

The keys property indicates a "cryptographic keys object" that has the properties of auth and p256dh.

auth

The auth property indicates the "authentication secret" as defined in the [RFC8291] specifications.

p256dh

The p256dh property indicates the elliptic curve Diffie-Hellman (ECDH) public key as defined by [RFC8291].

Note: Let the predicate push:endpoint be an rdfs:subClassOf of notify:sendTo?

2.1. Subscription Example

This section is non-normative.

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

POST /subscribe/
Authorization: DPoP <token>
DPoP: <proof>
Content-Type: text/turtle

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix as: <https://www.w3.org/ns/activitystreams#> .
@prefix push: <https://purl.org/solid-web-push/vocab#> .
@prefix notify: <https://www.w3.org/ns/solid/notification#> .

<>  a notify:WebPushChannel2023;
    notify:topic <https://uvdsl.solid.aifb.kit.edu/inbox/>;
    notify:sendTo <https://fcm.googleapis.com/fcm/send/ezblK6NIv80:APA91bHrjqImGaqs5-kcIZ_zO72HVDHGfnrzi9xwJvSsHD3qu4js1nQfHvcjf1Fjgo3mpxBqMkFcqPdiaRPFXnYSkEf9yz78m9FFBaWzwIvmaQ8M1-2vxaAO3S-ha2jf7ALLqRP92Y9z>;
    push:keys   [
        push:auth "Z51Yn6DRglyzR6SpDYHkqw"^^xsd:base64Binary;
        push:p256dh "BNocq-WqQufNxY5NtFWz-ckbLoCprrHT74ALR-DXcpCoKmqV2cVflQ6ibyas-vJBMWMLeSDPdRBbJhcc0lDmJ5g"^^xsd:base64Binary
    ] .

Note: TODO check data types of auth and p256dh.

A successful response will have a HTTP status code of 201 Created and full notification channel description in the body.

The Subscription Service, in our example /subscribe/, where the POST request is submitted to:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dc: <http://purl.org/dc/terms/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix push: <https://purl.org/solid-web-push/vocab#>.
            
<#web-push> a notify:SubscriptionService;
    as:name "Solid Web Push"@en;
    rdfs:label "Solid Web Push Service"@en;
    notify:channelType notify:WebPushChannel2023;
    push:vapidPublicKey "BAOxV1U1Hj5npToInct2VhhYpJkL0GmHqc-ADbHu7O8Z2CJNkqSzc8BfCStWbTKq_yT9B6g6kYjyEHrAEpVuqww"^^xsd:base64Binary.

For Unsubscription,

3. Authentication and Authorization

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