Client can trust notifications are not forged.

[brownhoward]

It may also be worth mentioning that a client should be able to trust that the notifications it receives aren't forged.

Originally posted by @justinwb in solid/notifications-panel#3 (comment)

[elf-pavlik]

I think we should use terms publisher / subscriber since in different subscription types client / server roles will change in different parts of the sequence.

Currently, WebHook subscription type defines a way for publishers to authenticate when delivering notifications.
Proposed LDN subscription type relies on the publisher providing webid which will be used to authenticate when delivering notifications.

To my understanding subscription types following subscriber connects to the notification source pattern will rely on notification source URL being provided by the publisher in subscription response.

I think we should consider having a section shortly addressing this aspect in each subscription type.

[csarven]

Noting here that this requirement was already covered as part of general requirements:

Ability to sign notifications and verify it hasn't been tampered with in transit.

in solid/notifications-panel#1 (comment) (2019) towards realising some of the use cases. We can approach a concrete requirement in a separate issue when the UCR is updated and there are proposals for a solution. Closing and marking as postponed.