Closed elf-pavlik closed 1 year ago
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.
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.
@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.
No problem with adding this, especially if it's being used in other subscription types.
@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)
WebHookSubscription2021 is going to be superseded by WebHookChannel2023 #146 which already uses notify:sender
.
LinkedDataNotificationsSubscription2021 uses webid in the subscription response explaining:
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