Repository navigation
Make AuthN/AuthZ of each channel explicit #155
Description
Activity
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:CapabilityURLand predicatenotify:authSchemewhich 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" }
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.
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" }
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
authSchememakes 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.
- added a commit that references this issue
on Jul 6, 2023
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:
Related issues: