Make AuthN/AuthZ of each channel explicit

[elf-pavlik]

Currently each channel doesn't specify AuthN/AuthZ method which it relies on. Instead we have implicit relying on what Channel type defines. I think each channel should specify what AuthN/AuthZ the receiver or the sender should use when receiving or sending notifications.

I'm going to track this issue inline in:

• WebHookChannel2023 #146
• StramingHTTPChannel2023 based on discussion in https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1574

Related issues:

• 134

• 148

• 18

[elf-pavlik]

I think the first step would be to make it explicit when Capability URL is being used for the receiveFrom and sendTo. I think we could simply define an individual solid:CapabilityURL and predicate notify:authScheme which would be used as part of Notification Channel description.

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/ac748712",
  "type": "WebhookChannel2023",
  "authScheme": "CapabilityURL",
  "topic": "https://example.org/guinan/profile",
  "sendTo": "https://webhook.example/d4cf3f19",
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

In case of the StreamingHTTP channel we could add alias to JSON-LD context "SolidOIDC": { "@id": "https://solidproject.org/TR/oidc" } and have

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/guinan/profile",
  "type": "StreamingHTTPChannel2023",
  "authScheme": "SolidOIDC",
  "topic": "https://example.org/guinan/profile",
  "receiveFrom": "https://example.org/guinan/profile.notifications",
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

[jaxoncreed]

Are there any use cases where the authScheme for a specific notification protocol wouldn't be the same in all occurrences? I mean future-proofing is fine, but at some point the continual atomization of concepts just adds complexity.

[elf-pavlik]

Since we want to describe the auth scheme for a specific URL, given that besides receiveFrom and sendTo we will also have URLs to unsubscribe and/or update subscriptions, it might make more sense to use that specific URL as the subject in the statements, so the examples above could change to:

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/ac748712",
  "type": "WebhookChannel2023",
  "topic": "https://example.org/guinan/profile",
  "sendTo": {
    "id": "https:/webhook.example/d4cf3f19",
    "authScheme": "CapabilityURL"
  },
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/guinan/profile",
  "type": "StreamingHTTPChannel2023",
  "authScheme": "SolidOIDC",
  "topic": "https://example.org/guinan/profile",
  "receiveFrom": {
    "id": "https://example.org/guinan/profile.notifications",
    "authScheme": "SolidOIDC"
  },
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

[elf-pavlik]

As mentioned during the call, the matrix of current channel types and auth schemes:

receiveFrom

type	implied	other in demand
WebSocketChannel2023	Capability URL	some token based approach
StreamingHTTPChannel2023	Solid-OIDC	Capability URL
EventSourceChannel2023	Capability URL

sendTo

type	implied	other in demand
WebhookChannel2023	Solid-OIDC	Capability URL, solid/specification#504
LDNChannel2023	Solid-OIDC	#148 , solid/specification#504

I think we need to support more than one channel type. Also keeping in mind that the ecosystem needs to be evolving. This year Capability URL might be the most accessible. Next year we may get something out of solid/specification#504. I don't think there is a need to update channel types as the ecosystem evolves. Something like the suggested authScheme makes it extensible.

I also would like to acknowledge that we will need a section in Solid Protocol (or a separate document) that requires a specific common subset of channel types and auth schemes to be supported for given version of Solid Protocol.