What if remote agents were able to use some plugins from local agents?

[mirceanis]

In Veramo 5.x (and probably also in 6.x) we have the option of connecting to remote veramo instances and executing their plugin methods as if they were local plugins. This is of great help as we can make use of resources unavailable in the local context.

BUT, there is a catch. If the remote plugin method being called relies on other plugins, those other plugins need to be installed and available in the remote agent as well. there is currently no way for a remote plugin to "call back" to the local context and execute a local method.

Here's a diagram representing a local agent trying to issue a credential using a remote credential plugin:

sequenceDiagram
    box Silver Local Agent
    actor LA as Local context
    end
    box Silver Remote Agent
    Actor RA as Remote context
    participant RC as Remote CredentialPlugin
    participant LK as Remote KeyManager
    end
    LA->>RA: issue VC
    RA->>RC: issue VC
    RC->>RA: sign payload
    RA->>LK: sign payload
    LK-xRA: signature
    RA-xRC: signature
    RC-xRA: credential
    RA-xLA: credential

Loading

Proposal

Let's examine another example, when the local agent is sitting in a browser, and able to use a crypto wallet as a key manager, but still wants to use a credential plugin implemented remotely.
In this case, the remote credential plugin would have to call back to the local key manager:

sequenceDiagram
	box silver Local Agent
    actor LA as Local context
    participant LK as Local KeyManager
    end
    box silver Remote Agent
    Actor RA as Remote context
    participant RC as Remote CredentialPlugin
    end
    LA->>RA: issue VC
    RA->>RC: issue VC
    RC->>RA: sign payload
    RA-->>LA: sign payload (***)
    LA->>LK: sign payload
    LK-xLA: signature
    LA--xRA: signature (***)
    RA--xRC: signature
    RC-xRA: credential
    RA-xLA: credential

Loading

For this to happen, the communication mechanism between the agents as well as an extra authorization mechanism would be needed, but before going into detail about that, I'd like to gather some general feedback about this proposal.

[damianglover]

I think this could be interesting as a way to potentially enable constrained IoT devices to issue their data as VCs, with access management to the VCs handled by the device's digital twin / remote agent while enabling the Device to retain control of its keys (assuming it is capable of doing this)

[0x62]

@mirceanis Did you explore this any further? I think it would be a very useful addition. My usecase for this would be an application where some keys are self custody (e.g ethr), and others are remote custody. The solution at the moment is essentially three agents - a remote agent, a lite client agent which uses the RemoteClient plugin and a full client agent for self-custody keys - but its far from ideal.

[mirceanis]

I did think about it some more, but haven't made actual progress since it didn't seem like there was much desire for this kind of setup.

My current mental picture includes something like an "execution context object" that gets passed around, so that when a remote agent calls back to execute some local agent method, it has limited permissions. This approach needs a language to describe the permission landscape in terms of plugin methods and data..

An alternative would be to create a special error that a remote agent can return describing the function it's missing so that the local agent can execute that function locally and then call a continuation function on the remote to get to a final result. This approach would require some form of execution state management on the remote, so that a continuation makes sense.

I like the first approach better as it would allow not just local-remote pairs, but a graph of agents to collaborate within the shared context.
I'm looking at UCAN as the format for the execution context.

Please share your ideas or requirements about this topic.

[0x62]

The "execution context" approach is also how I pictured it, but I'd imagine this would still require some kind of remote state. If we permission-ed it at the plugin method level we'd also need some form of introspection of each methods dependencies (which could be several levels deep) in order for the local client to know what methods it can call (e.g you could have the keyManagerSign, but without keyManagerGet you couldn't actually use the sign method, and this would also apply across plugin boundaries).

Each KeyManager would also need context on which agent controls which key. There could either be a handshake process where each agent proactively shares it's capabilities, keys, DIDs etc, or an agent could lazily query connected agents if it can't fulfill a given request locally.

I'd also be in favor of introducing a WebSocket transport method for agent-agent communication to reduce latency in N>2 graphs, although this would be a secondary goal.

UCAN makes sense for the authorization. I'm picturing each plugin has a unique namespace, and then permissions can be applied to bot it's methods and resources. Each agent instance could either have it's own identity keypair (e.g a special did:key), which handles authn for all local resources, or the UCANs could be issued directly by the managed keypair they relate to.

Even in the former case, I could imagine scenarios where multiple UCANs would be required for a single operation. For example, a local agent calling issue VC on a remote agent, signed by a key managed by a tertiary remote agent. In this case, you might have one UCAN for keyManagerSign on the intermediary, and a second UCAN for the VC agent that authorizes CRUD operations on the VC store. Definitely a convoluted use-case, but if graphs of arbitrary depth are to be supported it might be needed.

[mirceanis]

The "execution context" approach is also how I pictured it, but I'd imagine this would still require some kind of remote state.

What kind of remote state did you have in mind?

If we permission-ed it at the plugin method level we'd also need some form of introspection of each methods dependencies

I guess the introspection can be solved by a manifest approach, where each plugin developer publishes a list of other plugis/methods it expects.
We were already thinking about something like this to be used as a config validation tool.
There is a proto-attempt at this in the monorepo where we define some IRequiredContext or IAgentContext data types. It's not even close to enough and it's not even enforced, but it's a start.
(BTW, suggestions welcome on how we can improve the typescript type validation / inference for agents)

Each KeyManager would also need context on which agent controls which key.

I think we can iterate on this by initially only separating on plugin method and later caring about the actual data. In this particular example, if it becomes easier to wrap veramo instances, a meta-keymanager can be created that multiplexes between local and remote key managers, and then this metamanager can be added to the execution context.

I was thinking along the same lines in terms of the usage of UCAN. I had a simpler picture in mind regarding the "graph of agents", where the local doesn't really need to know what's behind the remote, so the graph doesn't really exist for it, but then this doesn't really exclude the possibility that multiple UCANs will be used. I also don't see this as a burden as this is what it was designed for.