Too Slow: Please provide Updates-Via shortcut to secure web socket address

[timbl]

In https://solid.github.io/notifications/websocket-subscription-2021
and https://solid.github.io/notifications/protocol
in order to watch (subscribe for notification of changes to) some resource, one has to go though many more round trips than are really necessary to set up the web socket.

Yes it is useful to have a generic notification architecture, and yes it useful to have pod-wide metadata, but going through that all to watch a given resource is too bad for performance.

Why not give the client a short cut to the end of the maze? Imagine that the client had done a subscription, and give the WSS secure address in the headers on the first GET.

[kjetilk]

Performance tests aside, I think I have gradually come to appreciate that there might be request-response pairs (ping-pongs for short) that under some assumptions aren't necessary.

The proposed protocol requires a discovery ping-pong, and then authorization ping-pongs. These might also be towards different servers, so it doesn't necessary help to keep connections open either. Though I have been an advocate for using a generic storage description to mitigate header bloat (which I see as problematic for IoT use cases, and because I think caching could help ensure that you wouldn't need to get the storage description all the time), on balance if we can have less ping-pongs in the overall protocol, then it is certainly worth using a header for it, like the current Updates-Via.

Then, the next assumption I would make is that a client that is authorized to access notifications of a resource, is also authorized to access to the resource itself. That could change at some point, but for now, it seems like a fair assumption that the access controls on the resource and its corresponding notifications are the same. Thus, the ping-pongs to authorize could be made superfluous, when accessing the resource, certainly the server could supply the token(s) required to access the notifications too?

With these two considerations, surely, the current Updates-Via could be extended so that it isn't necessary to access a separate discovery mechanism and also not necessary to check authorization separately?

[elf-pavlik]

We discussed this issue today during the call. @acoburn mentioned scalability issues when using Websockets this way, as well as possible problems with aggressively issuing Capability URLs for all requests.

From my side, I could investigate how this can be done with StreamingHTTPSubscription2021 which doesn't rely on Capability URLs and uses the same AuthN/AuthZ as any other HTTP request. If we want to have a such special case, taking advantage of streaming HTTP responses seems to me the most straightforward approach.

[elf-pavlik]

Thus, the ping-pongs to authorize could be made superfluous, when accessing the resource, certainly the server could supply the token(s) required to access the notifications too.

@kjetilk what advantages do you see in defining a flow with some custom token, compared to using Capability URLs?

[kjetilk]

On torsdag 29. september 2022 23:48:42 CEST elf Pavlik wrote: @kjetilk what advantages do you see in defining a flow with some custom token, compared to using [Capability URLs](https://www.w3.org/TR/capability-urls/)?

I think Section 4 in that spec describes it pretty well. I'm particularly concerned that in this case, the URI itself is sensitive. Tokens are clearly things that must be protected, URIs shouldn't be secrets in general. I would prefer to use capability URIs very sparingly, and when there are no options, only very short-lived capability URIs.

[elf-pavlik]

I don't think it is clearly stated, but to my understanding, we assume that the Capability URL provided as source in the subscription response expires together with the subscription, I think the expiration should also be provided in the subscription response. In the Updates Via, the expiration time would need to be provided as an additional parameter. I still think this might be more straightforward than introducing custom tokens.

Given all the above, I still think that using streaming HTTP, rather than Websockets, saves us from having to use different AutnN/AuthZ mechanisms. Maybe before trying to find a solution to the problem with Auth over Websockets we could clarify why to take the problematic path in the first place?

[kjetilk]

I understand the desire to go for streaming HTTP, but this is about a minimal change.

With capability URLs, this is an example of an attack that I fear:

Say that Alice sets up a pod with append permissions to a large group of people, which is an expected thing to do. Mallory are amongst the users that gets append access to a resource on Alice's Pod. Now, say that Bob comes along, and Alice has given Bob read permissions on the resource.

Say that Mallory appends a message with "Cute kittens here: https://mallory.example/pics/cute-kitten.jpg" and Bob has a subscription to the resource, gets notified and clicks that link, sees cute kittens and has no reason to suspect that something is wrong. However, Bob's UA may have leaked the capability URL to Mallory since Mallory controls his server, through e.g. the Referer header or some other mechanism as indicated in the Capability URLs WD. Now, Mallory would have escalated his privileges to read notifications, right?

I would prefer to reserve capability URLs for cases where they are single-use.

As for expiration, indeed, a subscription is a commitment into the future, so it makes sense to set expiry and have clients redo auth* now and then.

[elf-pavlik]

@kjetilk I created a dedicated issue to discuss the scenario you brough up #115

[CxRes]

With the impending release of the revised spec, I believe we can re-introduce updates-via like headers. I propose that we allow the resource to advertise two headers, for any one "notification channel" and/or for any one "subscription resource", both chosen from the respective lists advertized in the discovery resource. The header values can simply be formatted as a serialized version of a "notification channel" and "subscription resource" data model.

We can debate whether to make this feature optional or mandatory (i.e. in cases where a notification service exists on a resource). Other than this, I do not see any other impediments in implementing this feature.

[csarven]

If we were to define a header, it needs Structured Field Values of HTTP https://www.rfc-editor.org/rfc/rfc8941.html

Link relation, although verbose may be simpler:

HEAD https://example.org/guinan/profile

Link: <wss://websocket.example/guinan/profile?auth=foobar>; rel="http://www.w3.org/ns/solid/notifications#receiveFrom"
Link: <http://www.w3.org/ns/solid/notifications#WebSocketChannel2023>; anchor="wss://websocket.example/guinan/profile?auth=foobar"; rel="type"

[CxRes]

Link relation, although verbose may be simpler
This is confusing for the client, especially if it could potentially be mixed with other link relations.

Why not just?

HEAD https://example.org/guinan/profile

Update-Channel: id="https://channel.example/guinan/profile"; type="WebSocketChannel2023"; receiveFrom= "wss://websocket.example/guinan/profile; rate="PT1M"

Mirroring Discovery Resource:

"channel": [{
    "id": "https://channel.example/guinan/profile",
    "type": "WebSocketChannel2023",
    "topic": "https://example.org/guinan/profile",
    "receiveFrom": "wss://websocket.example/guinan/profile",
    "rate": "PT1M"
  }]

and similarly for Subscriptions in another header (with potentially two sub-cases: Subscription specific to topic and Subscription specific to pod).