Notification Sender - authentication may require both identities client & agent (user)

[elf-pavlik]

Previous drafts were using webid in Subscription Response (Webhook, LDN). Recently we changed it to sender.

Commonly solid authentication provides two identities:

• client - the application (e.g. used by acp:client matcher)
• agent - the end user (e.g. used by acp:agent matcher)

I think having just single WebID as sender doesn't support case where access policy on the target should be based on two identities client and agent. We should consider supporting providing both identities for the sender.

[csarven]

My understand was that sender is more generic but probably more aligned with client. sender is strictly driven by the notification-server which is a software, as opposed to a person or a social entity, so not agent in that sense.

I can see the notification-server (the sender or client) authenticating at target in order to send the notification but I don't see how authenticating agent would work here, i.e., without introducing things like delegation (e.g., used by acl:delegates). So, the mention of agent in the payload of a notification would only be a claim that can't be verified - at this time at least.

[elf-pavlik]

Let's consider a case where we have two Subscribtion Servers run by two different organizations:

• https://subscribe.acme.example
• https://subscribe.yoyodyne.example

Both ACME and Yoyodyne use the same 3rd party Notification Sender:

• https://sent.example

Now Alice creates a Webhook (or LDN) subscription with sendTo: https://hooks.alice.example/acme
If response only provides sender: https://sent.example, there seems to be nothing stopping Yoyodyne or any other user of https://sent.example to send notifications to https://hooks.alice.example/acme.

In this case it might more sense in response to provide sender: https://acme.example, which would allow ACME to deliver the notification using https://sent.example or any other Notification Sender they choose to use. While the channel is active ACME should be able to switch from https://sent.example to https://delivered.example. This is in lines with Solid premise of enabling any Social Agent to freely choose applications (clients) which they use to interact with data spaces.

[csarven]

If response only provides sender: https://sent.example, there seems to be nothing stopping Yoyodyne or any other user of https://sent.example to send notifications to https://hooks.alice.example/acme.

My understanding was that the sender is mentioned so that NotificationReceiver can authorize sender. I'm not sure if there is any expectation that anyone else would be able to send messages to NotificationReceiver. The NotificationReceiver needs to be informed about sender -- which is currently unspecified.

[elf-pavlik]

If both ACME and Yoyodyne use https://sent.example as their Notifications Sender. Once Alice grants access to a specific sendTo to https://sent.example. If Yoyodyne knows that sendTo URI, they could all by themselves create a channel with the same sendTo and have https://sent.example deliver notifications there, without Alice opting-in in any way.

We might need to rely on Capability URLs for sendTo, and in this case we would not need any sender information.
Possibly we should have an explicit way of defining if sendTo and receiveFrom are capability URLs or they rely on some other AuthN/AuthZ mechanism.

[elf-pavlik]

The sequence diagram below shows the issue I described in previous comment.
We consider notfify:sender being set to sent.ex Notifications Sender, which acts as a client on behalf of various social agents: ACME, Yoyo etc.
We don't assume sendTo being a capability URL since we want to rely on some different AuthN / AuthZ

sequenceDiagram
  participant Alice as alice.ex (NR+SC)
  participant Sent as sent.ex (NS)
  participant ACME as acme.ex (RS+SS)
  participant YOYO as yoyo.ex (RS+SS)

 Alice ->> ACME: Subscribe to gadgets { sendTo: alice.ex }
 ACME ->> Alice: Channel A { sender: sent.ex }
 Note over Alice: sets access for send.ex
 ACME ->> Sent: Notify Channel A about gadget X
 Sent ->> Alice: Deliver Notification { object: acme.ex/gadget-x }
 Note over Alice: OK expected notification from acme.ex via sent.ex
 YOYO ->> Sent: Notify Channel A about fake Y
 Sent ->> Alice: Deliver Notification { object: yoyo.ex/fake-y }
 Note over Alice: Oops! span from yoyo.ex via sent.ex

Loading

I think notify:sender should be set to the social agent, in our case acme.ex which would prevent yoyo.ex sending spam.
We should also support that ACME can switch to a different notification sender (acting as client) while the channel is still active. Let's say ACME uses sent.ex for some time and later migrates to hermes.ex.

Clean approach would rely on ACME giving explicit Authorization to the Notifications Sender they use (which acts as a client) and that client uses that authorization while making request. UMA claims pushing which is recommended approach in Solid-OIDC could push such authorization as a claim while obtaining the access token from alice.ex Authorization Server.

BTW Solid-OIDC is not really a great fit here for sent.ex or hermes.ex since they both act as server side clients and there is no end-user involved to go through the Authorization Code flow.

[jaxoncreed]

Perhaps this is not what you were hoping to solve, but as I understand it, Capability URLs will not solve the authentication problem from the perspective of the alex.ex. alex.ex cannot trust any url because, under a webhook system without signed keys, any sender can claim to be any other sender.

[elf-pavlik]

As we discussed during the panel (under #9 ) when sendTo is a Capability URL, only the sender knows it so it's pretty much used as a shared secret between the sender and the subscriber/receiver.

[elf-pavlik]

We can use this diagram during today's call about AuthN/AuthZ

sequenceDiagram
  autonumber
  actor A as Alice
  participant DC as Discovery Client
  participant SC as Subscription Client
  participant NR as Notification Receiver
  participant NS as Notification Sender
  participant SS as Subscription Server
  participant RS as Resource Server
  actor ACME
  DC -->> RS: Discover
  SC -->> SS: Subscribe
  alt receiveFrom
    NR -->> NS: Pickup
  else sendTo
    NS -->> NR: Deliver
  end
SC -->> SS: Unsubscribe

Loading

1. Discover

Discovery Client makes a request to a Resource Server. Currently, the notifications system doesn't assume AuthN/AuthZ to play a role here. #110 has some conversations about relying on AuthN/AuthZ in this step to provide Capability URLs or some tokens that can be used by the Notifications Receiver.

2. Subscribe

Subscription Client makes a request to a the Subscription Server. Currently, this is the main point of AuthN/AuthZ. For many notification channel types, Capability URLs are provided in this step.

3. Pickup

Notifications Reciever connects to the Notifications Sender, this is the case for receiveFrom based channel types. Many channel types rely on Capability URL being used for the receiveFrom.
Some channel types allow AuthN/AuthZ in this step.

4. Deliver

Notifications Sender connects to the Notifications Receiver, this is the case for sendTo based channel types. #155 suggests that AuthN/AuthZ scheme used can be made explicit for a given channel. Capability URLs as well as other AuthN/AuthZ systems can be used here.

5. Unsubscribe

Subscription Client connects to the Subscription Server. As discussed in #145, in some cases the same AuthN/AuthZ as used in the Subscribe step can be used, in other cases may require unsubscribing only based on the information provided in each notification.