Currently Notification Protocol only defines Subscription. WebhookSubscription2021 defines unsubscribing, IMO it should also be defined on the protocol level so that it can be used with any channel type.

I see few aspects that need to be clarified

Including unsubscribe details in subscription response

This seems reasonable for notification channel description to provide details needed to unsubscribe
It makes sense that authentication should use same identity as subscription client which made subscription request.

Including unsubscribe details in each notification

WebhookSubscription2021 also requires that unsubscribe details are included in every notification.
Besides that it posts a question in Further considerations

The fact that the Pod allows any URI to be submitted as a target might lead to distributed denial of service attacks originating from Pods. A malicious actor could create an app and trick many users to join it. The malicious app would then create a webhook targeting its desired target. It may be a good idea to build in an automated verification process to confirm that the entity sending the subscription request also owns the target webhook endpoint.

Given above it might make sense to use Capability URL in each notification and don't require authentication on it. This way one can at least unsubscribe from notifications where malicious actor made the subscription.

/cc @jaxoncreed