Open elf-pavlik opened 1 year ago
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
Previous drafts were using
webid
in Subscription Response (Webhook, LDN). Recently we changed it tosender
.Commonly solid authentication provides two identities:
acp:client
matcher)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 identitiesclient
andagent
. We should consider supporting providing both identities for the sender.