Public method for signing a transaction

We are developing a software in .NET for interacting with IC using the EdjCase.ICP.Agent nuget package (https://www.nuget.org/packages/EdjCase.ICP.Agent). Our software basically consists of two components: the server side app (webapi) and the client side app (a console app), that securely holds the private key.

In our flow, the transaction submission process is divided into 4 steps:

1. on the server side - prepare the transaction to be signed,
2. on the client side - retrieve the (nonsigned) transaction from the server side, sign it and send the signed transaction back to the server-side,
3. on the server side - submit the signed transaction to the IC using HTTP.API,
4. on the server side - check the status of the transaction.

In the EdjCase.ICP.Agent library, steps 1-3 are performed within a private SendAsync method:
https://github.com/BoomDAO/ICP.NET/blob/93072497d0ea15e1460bb4161c4e39b7066c5851/src/Agent/Agents/HttpAgent.cs#L229.

What we would need to accomplish our flow, is to split this private method into 3 separate public methods:

Can this functionality be added to the EdjCase.ICP.Agent nuget package?

[Gekctek]

Its possible, i think I would need a bit more information
The hardest part would be allowing access to these lower level APIs and keeping the library abstracted from HTTP

From what I understand, you really just are sending it with an identity that is on a different computer, so it just needs to be signed somewhere else. There are 2 ways I can think of maybe implementing this

• Delegated Identity would be the easiest, because that can be done now. Essentially you generate a key on your api server, then that is sent to your client, which then signs a delegation chain to allow the api server key to send the request(s) using its private key with a limited scope/time.
• Remote identity. This would have to be added, but essentially we could make it so that there is a new identity type that makes a call to the client to sign the request, then on response, the server could use that signature and send it off. This would require more work and maybe API changes but i think it would be possible.

I guess a question is how much is the client checking, or is it just signing whatever it is given, just to have the key seperate. Or is there high security validation that the request is perfectly correct by the user?

[misha-fm]

Hi, @Gekctek! I would like to reopen this issue with some more details.

Currently, ICP.NET library does not provide a way to separately sign a message and then submit the already signed message to the server. This limitation makes it difficult to implement workflows where signing and submission occur on different devices.

Use Case / Motivation:
In our scenario, a user holds their private key on their mobile device and signs a CallRequest locally. The signed message is then sent to a server, which subsequently submits it to the Internet Computer. This separation of concerns enhances security by ensuring that private keys never leave the user's device.

For comparison, NEthereum provides such functionality, allowing developers to sign messages independently and send them separately. Adding similar support to this library would enable more flexible and secure architectures.

Proposed Solution:
A possible implementation should allow:

1. Generating a CallRequest that can be signed separately.
2. Signing this request externally (e.g., on a mobile device) without submitting it immediately.
3. Sending the signed request to a server.
4. The server submitting the signed request to the Internet Computer.

I have drafted an approach in this commit in a fork: CoreLedger-TEOS@674581b

Please let me know what you think about suggested approach.

[Gekctek]

@misha-fm Happy to help now that im back from EthDenver
I have looked at your fork code and im still a bit confused on the process and i want to design it around the case

• Why doesn't the client just submit the request themselves?
• Is the client using ICP.NET? if not it might make sense to have something a bit more generic to send back and forth vs having ICP.NET handle both client and server
• If the client is using ICP.NET, is the server using it too?

Ill try to put something together based on your fork

[misha-fm]

@Gekctek Hi! Hope you enjoyed the conference!

Why doesn't the client just submit the request themselves?

well, that's our architecture. the server (TxServer) is responsible for processing transactions, signed on different user devices for different blockchains. so on devices, that trust TxServer, we only sign them, as we want the private keys to be only stored on user devices. and afterwards the signed transactions are sent to TxServers, that knows the server stuff, related to concrete blockchain instances used (eg api address of the ICP or the addresses of json-rpc endpoints in case of ethereum).

Is the client using ICP.NET?

the client uses the part, that is related to signing process. please see the example, where I tried to show the usecase, here: CoreLedger-TEOS@674581b#diff-70f6969241f31b7ab3ac4ab54783e66cd4f19d86a8cfc7a5eea84aeb0011dd99R56

so on clients we need anyways all the types, specific to ICP architecture - signing algorithms, request id retrieval, etc.
This can be of course delivered as a separate package, eg Icp.Net.Signer (similar to https://www.nuget.org/packages/Nethereum.Signer).

If the client is using ICP.NET, is the server using it too?

the server uses ICP.NET to submit transactions aka calls to the ICP, update their statuses in background, validate the transactions.

hope the answers help to better understand our solution.

[misha-fm]

to clarify a bit more.

the client and the device are running on separate devices/machines and only communicate with each other via HTTPS.
Probably you were confused by the code, where I had both client and server used in the same class, but this is just for simplicity and for example. In real-world scenario they are of course running in separate processes on different machines.

[Gekctek]

Alright, will have to play with it to see what design to make it intuitive/easy to use. Ill see what i can do and get something out

[Gekctek]

As an update, i have made good progress and I think I landed a good design that should fit your needs, will include breaking changes
But essentially Im changing the IAgent to accept SignedContent and having helper methods auto sign for your IIdentity if you want to
Then ill probably break out the signing components and make that a good experience to use too

Preview:

	public interface IAgent
	{
		Task<CandidArg> CallAsync(SignedContent<CallRequest> content, Principal? effectiveCanisterId = null, CancellationToken? cancellationToken = null);
		Task<RequestId> CallAsynchronousAsync(SignedContent<CallRequest> content, Principal? effectiveCanisterId = null, CancellationToken? cancellationToken = null);
		Task<CandidArg> QueryAsync(SignedContent<QueryRequest> content, Principal? effectiveCanisterId = null, CancellationToken? cancellationToken = null);
		Task<ReadStateResponse> ReadStateAsync(Principal canisterId, SignedContent<ReadStateRequest> content, CancellationToken? cancellationToken = null);

		/// <summary>
		/// Gets the status of the IC replica. This includes versioning information
		/// about the replica
		/// </summary>
		/// <returns>A response containing all replica status information</returns>
		Task<StatusResponse> GetReplicaStatusAsync(CancellationToken? cancellationToken = null);

		/// <summary>
		/// Gets the root public key of the current Internet Computer network
		/// </summary>
		/// <param name="cancellationToken">Optional. Token to cancel request</param>
		/// <returns>The root public key bytes </returns>
		Task<SubjectPublicKeyInfo> GetRootKeyAsync(CancellationToken? cancellationToken = null);
	}

[Gekctek]

@misha-fm Do you have a requirement for the library to split out the signing parts to its own package or are you ok with it all being in the EdjCase.ICP.Agent package, as long as its easy to use

[Gekctek]

@misha-fm could you try https://github.com/edjCase/ICP.NET/releases/tag/8.0.0-pre.1
and see if it works for you