Include webid in subscription response to use standard AuthN

[elf-pavlik]

LinkedDataNotificationsSubscription2021 uses webid in the subscription response explaining:

All LDN notifications will be sent to the defined inbox using the agent identity specified by this WebID. A resource owner should ensure that the agent identified in this property is permitted to send authenticated HTTP requests to the defined inbox.

I think WebHookSubscription2021 and all target flow types, in general, could use this as a common approach.

@jaxoncreed what do you think about using this approach instead of defining custom AuthN?
https://github.com/solid/notifications/blob/main/webhook-subscription.md#10-webhook-request-with-token-signed-by-the-pod-key

[jaxoncreed]

I don't know if I understand this correctly. Are you saying that every notification would be directed at an LDN inbox? If so, doesn't that defeat the point of a WebHook since the Webhook API endpoint isn't an inbox?

I'm probably just not understanding the proposal.

[elf-pavlik]

I'm not proposing to mix any LDN specific constructs into the WebHook subscription type.

I just use it as an example of providing agent identity in the subscription response. This in turn could be used to set access policy on WebHook target, this way common AuthN mechanism (for example Solid-OIDC) could be used when posting notification to the target. Taking that approach the WebHook subscription type wouldn't have to define a custom AuthN mechanism to be used for the delivery of notifications.

EDIT: Current custom AuthN seems to be assuming that solid storage hosting the topics will be the party that delivers the notifications. In #49 I suggest that we shouldn't assume that.

[elf-pavlik]

@jaxoncreed I recall this being discussed some time ago, are you open to making this change to the webhook subtype?
I also will start using https://github.com/o-development/solid-webhook-client in the next few days. I already have code to verify Solid-OIDC authentication so it would be great if I would get the expected webid of the agent which will deliver notifications. I don't intend to discuss your implementation here, just mentioning it and my intent to start using it.

[jaxoncreed]

No problem with adding this, especially if it's being used in other subscription types.

[elf-pavlik]

@michielbdejong FYI I plan to make PR to resolve this issue sometime this weekend. This will remove the need for custom AuthN and just provide webid in the subscription response which will be delivering notifications to the subscription target (webhook callback) using a general AuthN mechanism (eg. Solid-OIDC)

[elf-pavlik]

WebHookSubscription2021 is going to be superseded by WebHookChannel2023 #146 which already uses notify:sender.