We need to integrate support for signing transactions explicitly into the protocols. This is because the implementation should be careful to sign only appropriately formatted messages: in our use case, this will transactions consistent with EVM/Ethereum.
To close this issue, address the following either directly in the spec (as part of a protocol or implementation guidance) or in a comment on this issue:
[ ] Consider including explicit internal-only TransactionApprovalRequests (TARs) with a corresponding identifier (that must be unique among request, i.e., an immutable, read-only field). Note: we should determine where/how this identifier is chosen, with the understanding that eventually we will have multiple key servers.
[ ] Determine how and whether to track transaction originators. (Or are these always the asset owner via a client? If not, what metadata should be kept about the asset owner as part of the TAR?)
[ ] A consideration of the architecture, both in the single server model but also extending to multiple key servers. Some questions were first raised in https://github.com/boltlabs-inc/key-mgmt/issues/26.
We need to integrate support for signing transactions explicitly into the protocols. This is because the implementation should be careful to sign only appropriately formatted messages: in our use case, this will transactions consistent with EVM/Ethereum.
To close this issue, address the following either directly in the spec (as part of a protocol or implementation guidance) or in a comment on this issue:
TransactionApprovalRequests(TARs) with a corresponding identifier (that must be unique among request, i.e., an immutable, read-only field). Note: we should determine where/how this identifier is chosen, with the understanding that eventually we will have multiple key servers.