[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 registration protocol for investor's personal information, we would like to support off-chain "sealed" registration.

Describe the solution you'd like

We would like to be able to accept off-chain message transactions similar to those for issuers, such as the PersonalInfo contract.
Specifically, we would like to define a "SealedTx" API like the one below to accept execution commands from account addresses.

• Endpoint: /sealed_tx/personal_info/register
• Parameters: Same as input parameters to 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 strings
• CanonicalRequestPath: Path part of 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 will be treated as an empty string.
Note: If RequestBody is empty, keccak256(RequestBody) will use keccak256("{}").

Signature and authentication procedure overview

Client Side (Create signature)

1. Generate CanonicalRequest from the information of the request to be sent.
2. Sign CanonicalRequest using the account's private key.

The generated signature is set in the header (called "X-SealedTx-Signature") and the request is sent.

Server Side (Verify 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. It is determined that the original request came from the recovered address and subsequent processing is carried out.