Skip to content
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

Closed
elf-pavlik opened this issue Mar 17, 2022 · 6 comments
Closed

Include webid in subscription response to use standard AuthN #48

elf-pavlik opened this issue Mar 17, 2022 · 6 comments
Labels

Comments

@elf-pavlik
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member Author

elf-pavlik commented Mar 17, 2022

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
Copy link
Member Author

@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
Copy link
Contributor

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

@elf-pavlik
Copy link
Member Author

@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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants