You can now send operations to a VM using a dedicated token mechanism. The list of operations is defined in the operator view of aleph-vm.
Auth workflow
The auth workflow was designed as a stateless way of interacting with a VM, without having to send messages on the Aleph network and without requesting a remote wallet signature for each operation.
It works by creating an ephemeral ECDSA Keypair. The public key is sent with every operations alongside the requested operation header which is signed by the ephemeral private key. To confirm ownership of the ephemeral Keypair, the pubkey token is itself signed by the user wallet.
X-SignedPubKey
The X-SignedPubKey is an HTTP header, which has the following structure :
The payload is a JSON dictionary with the following content:
{
"domain": <string> // the domain name of the crn running the VM,
"address": <string> // the address of the VM owner,
"expires": <ISO-8601 string timestamp>
"pubkey": <JWK>
}
X-SignedOperation
The X-SignedOperation is an HTTP header, which has the following structure :
Feature description
You can now send operations to a VM using a dedicated token mechanism. The list of operations is defined in the operator view of aleph-vm.
Auth workflow
The auth workflow was designed as a stateless way of interacting with a VM, without having to send messages on the Aleph network and without requesting a remote wallet signature for each operation. It works by creating an ephemeral ECDSA Keypair. The public key is sent with every operations alongside the requested operation header which is signed by the ephemeral private key. To confirm ownership of the ephemeral Keypair, the pubkey token is itself signed by the user wallet.
X-SignedPubKey
The X-SignedPubKey is an HTTP header, which has the following structure :
The payload is a JSON dictionary with the following content:
X-SignedOperation
The X-SignedOperation is an HTTP header, which has the following structure :
The payload is a JSON dictionary with the following content: