Define unsubscribing

[elf-pavlik]

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

[CxRes]

Unsubscribe must be handled in the main protocol. I believe it is handled consistently as a subcase of subscription modification, as discussed in #103 and further in meetings.

I propose that we allow clients to POST a partial of Notification Channel Data Model, that is, only the property the clients wants to change to the Subscription Service. In case we wish to unsubscribe, this will simply be an id and endTime:

{
  "@context": [
    "https://www.w3.org/ns/solid/notifications/v1"
  ],
  "id": "https://channel.example/ac748712",
  "endAt": "time:Instant"
}

It can alternatively be a PUT with the above message or even a DELETE on the created subscription endpoint in case the Subscription Service is a container.

This will take away the need to add unsubscribe information in the subscription response or message!

[CxRes]

There is one other complication involved, which I had raised in a discussion two years ago https://gitter.im/solid/specification?at=5ea2b8c6501f8f72a5ffa61a. Some clients might want to continue to watch resources that have been deleted, in the expectation that they will be created again, other times we want to stop watching. I believe the proposal I make above is suitable to handle both these cases.

Aside: I would really like this to be handled as a feature, where the client can specify the behaviour beforehand rather than closing or staying after the deletion.

[jaxoncreed]

Another feature to consider:
Subscribers should be able to request a list of documents that they are subscribed to.

[jaxoncreed]

I propose that we allow clients to POST a partial of Notification Channel Data Model, that is, only the property the clients wants to change to the Subscription Service. In case we wish to unsubscribe, this will simply be an id and endTime:

I don't see any problems with this solution.

[CxRes]

Another feature to consider:
Subscribers should be able to request a list of documents that they are subscribed to.

Do you mean:
a. List of Topic Resources
or
b. List of Subscriptions/Channels that a particular client can connect/is connected to.

Both, are use useful features. Depending on your answer, we can open new issue/s?

[CxRes]

I don't see any problems with this solution.

From what I understood from our discussion, the question is if we want to use POST or DELETE?

POST has the benefit of specifying a later end time.

DELETE on the other hand, is more intuitive, if we think of Subscription Service as a container and each Subscription as a Resource. (There are other benefits for the treating the Service as a container, e.g. one can GET on the container to solve (b.) above)

I see no reason why we cannot support both?

[csarven]

Unsubscribing can indeed work with requesting to update (POST) the notification channel or removing it (DELETE).

There needs to be a clarification on the constraints on the notification channel resource ( #158 ) - the kind of IRI.

If the notification channel is not an HTTP URI, DELETE is not possible. POST targeting a subscription service can work with a IRI for notification channel in the payload.

Subscription service needs to be able to respond with a 201 with Location header referring to the notification channel resource in order to be able to later DELETE. However, subscription service is not required to be a container. It just has similar behaviour that can work with some existing implementations ( #36 ).

The payload of POST targetting a subscription service does not currently have a meaning on the value of the id property ( https://solid.github.io/notifications/protocol#notification-channel-data-model ). Which BTW needs an update because as it reads right now by following https://solid.github.io/notifications/protocol#subscription , the notification-channel-data-model is suitable for the response but not the request, i.e., as if the request should include notification channel id, and obviously that's not meaningful.

As it stands, the specification is effectively saying, no id means create/issue notification channel, and id means update (if exists) in the subscription request. That needs to be a bit more clear in the spec.

That approach can work but I stress again that we should be careful about this model.

Not too long ago we were looking into SubscriptionRequest: https://github.com/solid/notifications-panel/blob/main/meetings/2022-12-15.md (see also #62 (comment) ). So, normally there'd be a Request activity and an Update activity in the payload of POST - irrespective of the vocabulary considerations.

Lastly, as it stands I don't believe "endAt": "time:Instant" will work since the value is expected to be in xsd:dateTime datatype.

[CxRes]

I stress again that we should be careful about this model.
Care to elabourate how we are not being careful, or what is missing from the consideration? I had proposed POST and PUT/DELETE as two separate options depending on whether we exposed the subscription endpoint (what you are calling notification channel resource (we need to bikeshed this)). For a 0.2.1/0.3.0 any of these mechanisms is OK.

Re id: I see no problem in the Client requesting the use of an id for a first request. If a server is already using or otherwise does not want to create said id, it can refuse the subscription request or create another id. If no id is provided, a server will always create one for you.

Actually, I would like an explicit URI per id because it also allows one to do a GET to get subscription parameters, list of topics (see @jaxoncreed's additional request above) or even audit more deeply (even if that URI isn't a contained resource). Doing an effective GET on subscription service using a POST is weird.

[elf-pavlik]

I see no reason why we cannot support both?

Do you mean that server would have MUST on both or either one? If the server can choose than the client must know which one to use. Probably this would need to be included in the Notification Channel description, as well as in every notification delivered to sendTo.