initial WebhookChannel2023

[elf-pavlik]

This is initial version following common template using by other subscription types.
We can add separate primer to provide more detail example like in WebhookSubscription2023.

I also created #145 to define unsubscribing on the protocol level, later webhook can further specify it if needed.

[jaxoncreed]

Thanks for this @elf-pavlik . I'll be sure to hop into the meeting next week and we can talk about things in-person as well.

[jaxoncreed]

I feel like this section is incomplete.

Pointing to Solid OIDC for the first use case (Subscription client MUST perform authenticated subscription request.) is fine as that use case is very clearly a client-pod relationship which is what Solid OIDC was designed to handle.

There are many questions left unanswered about the second use case (Notification Sender MUST perform authenticated request to sendTo webhook endpoint, using identity provided as sender in the subscription response.).

• Are we saying that a sender's "authenticated request" needs to be Solid OIDC as implied by the Solid Notifications Protocol?
• If so, what role is the sender? Is the sender the token issuer? Is the sender the token subject?
• In my opinion, Solid OIDC is an inappropriate Authentication protocol for this use case. It's designed for use cases that involve a user agent, and therefore has more complexities than are needed. This use case is a simple server-to-server communications, but the following unnecessary things would be required if we were forced to use Solid OIDC:
  • An identity provider, not for users, but the send itself
  • The use of DPoP tokens which are not needed because DPoP tokens are designed for ecosystems that have three constituents: Identity Provider, Relying Party, and Resource Server.
• I've been out of it for a bit. Perhaps Solid OIDC has added the Client Credentials flow. If so, this does solve the DPoP token problem mentioned about as Client Credentials doesn't use DPoP, but it still requires extra complexity because the the sender would need to authenticated with an identity provider before sending notifications.
• I still prefer the method I outlined in the original document: Just give the sender its own public/private key pair and let it mint a simple token itself without needing to get a Solid OIDC IdP involved. Again, I've been out of it, so if there's an explanation as to why this approach is worse, I'm happy to hear it.
• But, no matter what approach we go with, I would still prefer to have this section go into a little more detail on how senders send authenticated requests.

[elf-pavlik]

@jaxoncreed I agree with all your points, recently I posted relevant comments on gitter
At the same time I don't think the problem is specific for WebHook channel type. I see it as more common requirement to authenticate server-side clients which we should be able to do in consistent way across the Solid ecosystem.
There is also #134 I just suggested that sendTo (former target) could be either a Capability URL or require some specific AuthN/AuthZ.

[elf-pavlik]

I'm going to add #155 as inline issue. This way we can already start using Capability URL for sendTo, later adding support for Solid-OIDC and other more fitting options.

[elf-pavlik]

[jaxoncreed]

This document doesn't mention how unsubscribing works. Is it described somewhere else?

[elf-pavlik]

Below you can see inline issue linking to #145

[jaxoncreed]

@elf-pavlik is the idea to just approve this to have something on the books and then fix the problems later?

[elf-pavlik]

@jaxoncreed I'd like to add any unresolved issues inline and try to publish 0.1 during next meeting.

EDIT inline issue added #146 (comment)

[TallTed]

Generally minor tweaks. A number of additional instances of WebhookChannel2023 (and possibly other entities) should also be wrapped in backticks.

[jaxoncreed]

Given the fact that issues are listed in this spec, I can approve it.