search

MellonScholarlyCommunication / spec-orchestrator

The implementation requirements for the Ochestrator component.
https://MellonScholarlyCommunication.github.io/spec-orchestrator/
1 stars 3 forks source link

Automatic processing of random notifications #2

Open Dexagod opened 3 years ago

Dexagod commented 3 years ago

I was looking into Authenticated Inboxes in the Linked Data Notifications spec, and it occured to me that if the orchestrator can be triggered by notifications in the pod inbox, this opens the door to forged notifications sent by external actors to your inbox, that are automatically picked up by the orchestrator component.

Some sort of verification mechanism should be added, so that all notifications that are picked up by the orchestrator can be verified by their sender.

Dexagod commented 3 years ago

The solution of authentication on the inbox seems a bit drastic, as this may impair other applications making use of the inbox. It might be worthwile looking into some sort of signing of the notification by the sender, and maybe even extending the policy language to only accept certain policies for notifications from a select group of senders?

Dexagod commented 3 years ago

I was also recently made aware of the possible creation of a working group on Linked Data Signature, where a draft proposal was submitted to W3C management for approval. I might ask for an update on this if it is deemed relevant for this usecase.

JWerbrouck commented 3 years ago

What would be the consequenses of having one or more access-controlled subContainers in your inbox, and a pointer to those inboxes to the relevant senders? Or access-restricted inboxes, e.g. tied to specific projects? That would involve a few extra steps in finding the project inbox from the hosting actor's WebID, but could allow more finetuning, as then I could point my orchestrator only to those inboxes I deem relevant for it to watch.

In my opinion, the orchestrator does not necessarily resolve to the object of "<#me> ldp:inbox ?object" . It could have its own, dedicated property, from a yet-to-be-created vocabulary. By default, it might point at the inbox of the actor. But if required, an actor kan keep their 'regular' inbox, while referencing another one (or multiple ones) for the orchestrator to watch.

As those will be specific/non-generic inboxes (i.e. created with a specific purpose in mind) it is likely that those will be acces-restricted, and hence more difficult to pollute with unwanted notifications?

mielvds commented 3 years ago

I was looking into Authenticated Inboxes in the Linked Data Notifications spec, and it occured to me that if the orchestrator can be triggered by notifications in the pod inbox, this opens the door to forged notifications sent by external actors to your inbox, that are automatically picked up by the orchestrator component.

good point

I was also recently made aware of the possible creation of a working group on Linked Data Signature, where a draft proposal was submitted to W3C management for approval. I might ask for an update on this if it is deemed relevant for this usecase.

Yes signatures are interesting to keep an eye on. However, it won't really solve the problem, since a signed notification can still cause havoc; you just know they came from where they say they came from.

Authenticated inboxes might be interesting if the orchestrator can apply different event filters when the inbox is authenticated. However, this would mean that the orchestrator listens to different inboxes after all, albeit controlled by the same actor.

mielvds commented 3 years ago

What would be the consequenses of having one or more access-controlled subContainers in your inbox, and a pointer to those inboxes to the relevant senders? Or access-restricted inboxes, e.g. tied to specific projects? That would involve a few extra steps in finding the project inbox from the hosting actor's WebID, but could allow more finetuning, as then I could point my orchestrator only to those inboxes I deem relevant for it to watch.

Conceptually, there is indeed no limit in inboxes. You could have as many as you want and they can be anywhere you want.

In my opinion, the orchestrator does not necessarily resolve to the object of "<#me> ldp:inbox ?object" . It could have its own, dedicated property, from a yet-to-be-created vocabulary. By default, it might point at the inbox of the actor. But if required, an actor kan keep their 'regular' inbox, while referencing another one (or multiple ones) for the orchestrator to watch.

I don't think an orchestrator will ever need to discover inboxes that it reads from, only those it writes to. Creating an orchestrator is a concious decision by an actor and thus, the inboxes it listens to should be explicitely configured. Unless we don't tie an orchestrator to an inbox, but to LDP resource(s), eg. <#res>. It would then listen to the inboxes <#res> ldp:inbox ?object. This would imply that the orchestrator is always watching one or more artefacts, would that make sense?

As those will be specific/non-generic inboxes (i.e. created with a specific purpose in mind) it is likely that those will be acces-restricted, and hence more difficult to pollute with unwanted notifications?

probably. How demanding is it to always require authentication? Maybe this is justified, since we are operating in a network. Another option would have the policy specify that you're not processing notifications from unauthenticated users.