diff --git a/.gitignore b/.gitignore
index 6227af2..3c1241d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ streaming-http-subscription-2021.html
webpush-subscription-2022.html
webhook-channel-2023.html
streaming-http-channel-2023.html
+webpush-channel-2023.html
diff --git a/webpush-channel-2023-flow.mmd b/webpush-channel-2023-flow.mmd
new file mode 100644
index 0000000..968e426
--- /dev/null
+++ b/webpush-channel-2023-flow.mmd
@@ -0,0 +1,32 @@
+sequenceDiagram
+ autonumber
+ participant Discovery Client
+ participant Subscription Client
+ participant Notification Receiver
+ participant Browser Messaging Service
+ participant Storage Metadata
+ participant Subscription Service
+ participant Notification Sender
+
+
+ Note over Discovery Client, Subscription Service: Discovery
+ Discovery Client ->>+ Storage Metadata: GET
+ Storage Metadata -->>- Discovery Client: 200 OK with Storage Metadata Representation
+
+ Note over Subscription Client, Subscription Service: Establish Channel
+ Subscription Client ->>+ Browser Messaging Service: Subscribe to Web Push Service
+ Browser Messaging Service -->>- Subscription Client: Web Push Subscription data
+
+ Subscription Client ->>+ Subscription Service: Submit subscription request to discovered subscription service via POST
+ Subscription Service -->>- Subscription Client: 201 CREATED
+
+ Note over Notification Receiver, Notification Sender: Deliver Notifications for Subscription
+ loop for each notification
+ Notification Sender -) Browser Messaging Service: Deliver notification
+ Browser Messaging Service -) Notification Receiver: Deliver notification
+ end
+
+ Note over Subscription Client, Subscription Service: Cancel Subscription
+ Subscription Client ->>+ Browser Messaging Service: Unsubscribe (delete subscription)
+ Subscription Client ->>+ Subscription Service: Unsubscribe (delete subscription)
+ Subscription Service -->>- Subscription Client: 204 No Content
diff --git a/webpush-channel-2023.bs b/webpush-channel-2023.bs
new file mode 100644
index 0000000..9cb897d
--- /dev/null
+++ b/webpush-channel-2023.bs
@@ -0,0 +1,292 @@
+
+Title: Solid WebPushChannel2023
+Boilerplate: issues-index no
+Shortname: solid-webpush-channel-2023
+Level: 1
+Status: CG-DRAFT
+Group: solidcg
+ED: https://solid.github.io/notifications/webpush-channel-2023
+Repository: https://github.com/solid/notifications
+Inline Github Issues: title
+Markup Shorthands: markdown yes
+Max ToC Depth: 2
+Editor: [Christoph Braun](https://github.com/uvdsl)
+Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net/)
+!Version: 0.1
+Abstract:
+ The [[!SOLID-NOTIFICATIONS inline]] 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 [[!PUSH-API inline]].
+
+
+
+This draft is based on a submission for [Web Push Notifications from Solid Pods](https://uvdsl.solid.aifb.kit.edu/conf/2022/icwe/demo).
+
+
+# Introduction # {#introduction}
+
+*This section is non-normative.*
+
+The [[!SOLID-NOTIFICATIONS inline]] 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 inline]] 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.
+
+## Terminology ## {#terminology}
+
+*This section is non-normative.*
+
+This document uses terminology from the [[!SOLID-NOTIFICATIONS]] protocol,
+ including "Notification Subscription Service".
+
+Issue(62):
+
+Note: Let the predicate `topic` be an `rdfs:subClassOf` of `as:object`?
+
+The document further uses terms from [[!PUSH-API]] specification,
+ including "push endpoint", "push service" and "authentication secret".
+It also uses terms from [[!OAUTH-2.0]] specification,
+ including "authorization server" and "access token".
+In addition, the document uses terms from the [[!WEBARCH]] specification,
+ including "information resource".
+
+This document uses the following terms as defined below:
+: browser messaging service
+:: Refers to the implementation of a "push service" [[!PUSH-API]] in a browser.
+
+
+## Overview ## {#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.
+
+
+
+ Solid WebPushChannel2023 Flow
+
+
+
+
+**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*.
+
+Issue(185):
+
+
+**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*.
+
+Issue(145):
+
+
+
+# WebPushChannel2023 Type # {#channel-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](https://solid.github.io/notifications/protocol#discovery).
+
+A WebPushChannel2023 SHOULD support the [Solid Notifications Features](https://solid.github.io/notifications/protocol#notification-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`?
+
+## Subscription Example ## {#example}
+
+*This section is non-normative.*
+
+An example `POST` request using a `DPoP` bound access token is below:
+
+
+
+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:
+
+
+
+
+For Unsubscription,
+
+Issue(145):
+
+
+# Authentication and Authorization # {#auth}
+
+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]].
+
+
+
+