[FEATURE] "SealedTx": Off-chain personal information registration

[YoshihitoAso]

Is your feature request related to a problem? Please describe.

In addition to using the PersonalInfo contract as a protocol for registering investors' personal information, we would also like to support off-chain 'sealed' registration.

Describe the solution you'd like

We would like to support off-chain message transactions similar to those used for issuers, such as the PersonalInfo contract. Specifically, we plan to define a 'SealedTx' API like the example below to accept execution commands from account addresses.

• Endpoint: /sealed_tx/personal_info/register
• Parameters: Same as the input parameters of the contract.
• Header: The signature of the account performing the transaction (X-SealedTx-Signature)

📔 "X-SealedTx-Signature" Specifications

CanonicalRequest =
HTTPMethod + '\n' +
CanonicalRequestPath + '\n' +
CanonicalQueryString + '\n' +
keccak256(RequestBody)

• HTTPMethod: GET, POST, or other HTTP methods as strings.
• CanonicalRequestPath: The path part of the URI (e.g., /sealed_tx/personal_info/register).
• CanonicalQueryString: Query string sorted by key (e.g., ?amount=123&card=hoge).

Note: If there is no CanonicalQueryString, it is treated as an empty string. Note: If the RequestBody is empty, keccak256(RequestBody) uses keccak256("{}").

Signature and Authentication Process Overview

Client-Side (Creating the Signature)

1. Generate a CanonicalRequest using the details of the request to be sent.
2. Sign the CanonicalRequest using the account's private key.
3. Set the generated signature in the header (as "X-SealedTx-Signature") and send the request.

Server-Side (Verifying the Signature)

1. Generate a CanonicalRequest from the received request.
2. Verify the X-SealedTx-Signature using the CanonicalRequest.
3. Recover the account address from the signature. If the original request matches the recovered address, proceed with the subsequent processing.