You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: