-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include webid in subscription response to use standard AuthN #48
Comments
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? |
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 |
WebHookSubscription2021 is going to be superseded by WebHookChannel2023 #146 which already uses |
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
The text was updated successfully, but these errors were encountered: