[Proposal] zkauth feature proposal

[zemyblue]

Background

Fischia-sdk, which is based on Cosmos-sdk, must sign through the signature key of secp2561k1 or secp256r1 to sign and verify Tx. And when signing like this, the address that becomes the subject of signing with the public key is induced. In other words, since the signature key and address are matched to 1:1 if the signature key is lost, the values owned by the address can no longer be used. Also, if it is stolen by hacking or the like, the stolen user can abuse it. That is why it is necessary to thoroughly manage the signature key. So, it is difficult for ordinary users to use it easily.

Proposal

Therefore, I propose a way to sign finschia-sdk without managing a separate signature key by using google OAuth or LINE messenger OAuth.
Similar to Sui's zklogin function, this feature allows the user to use the temporarily issued key only for a certain period of time by authentication through OAuth. And the relationship between authentication through OAuth and temporary key over a certain period of time can be used without being disclosed if evidence is generated and verified by zkp. This method allows the user to sign through OAuth when necessary without having to manage the signature key separately. Let this function be called zkauth.

How it works

Preparing to create tx with OAuth

1. Generate a temporary signature key.
2. User authentication is performed through OAuth.
3. Unique information such as OAuth Provider, client_id, and user_id is extracted from the user authentication information.
4. Set the max_block_height to use the temporary period. (The limit should be set so that the period of use does not become infinite.)
5. Proof is generated using the unique information of OAuth and the public key of Imshiki and max_block_height using zkp.

Signing and Verifying with OAuth

1. Verify that the available max_block_height of the temporary signature key has passed.

• If max_block_height has already been created or is close to it, it generates zkp evidence by generating a new temporary signature key again.

2. Make MsgZKAuth Message with the evidence of the desired message and zkp and sign it with a temporary signature key.
3. Send tx to the chain.
4. If the corresponding tx is ZKAuth message, the chain verifies zkauth, not auth.
5. In zkauth, the message in MsgZKAuth is passed to another module that can actually be executed.

the part that needs to be developed

• zkp circuit: Information such as OAuth's unique information, temporary signature key, and max_block_height can be generated and verified as validation evidence of the temporary signature key.
• zkp prover back-end: The providing key of zkp can be difficult to proceed with the client because it has a large capacity and uses a lot of resources to generate evidence. Therefore, we need a back-end server that can handle this quickly.
• x/zkauth module: native module of finschia-sdk that can verify and execute zkauth's tx
• zkauth sdk: SDK that helps you easily authenticate OAuth and create zkp prover back-end and tx on front-end.

Address

Since the address of zkauth cannot be generated from the temporary signature key, based on OAuth's unique information, it should be unique information that can represent the user even if the temporary signature key continues to change. Let's configure this in a way similar to Sui's address_seed as follows.

• address_seed = Poseidon_BN254(kc_name_F, kc_value_F, aud_F, Poseidon_BN254(user_salt))
• address_data = Blake2b_256 (iss_L, iss, address_seed)
• zkauth_address = beck32.ConvertAndEncode(hrp, address_data)

MsgZKAuth

MsgZKAuth is a message that contains actual message to be executed and zkp evidence information, which is the same as general message, but only when zkp verification is additionally performed, the part signed by the user with a temporary signature key can be verified through OAuth.
And since we need to make evidence through zkp, this tx has to be signed with Ed25519. Currently, finschia-sdk does not support Ed25519 with EOA signature key, so this part needs to be unlocked so that signature verification can be done.

Things that need improvement

• With signature via OAuth, the user does not need to manage keys, but the size of the tx gets a little bigger because it contains zkp evidence. So the gas fee can be increased. Improvements are needed to minimize this part.
• A dual verification device is required to prevent the user's assets from being used without the user's permission even when OAuth is seized. This part can be partially improved by using the multisig method using x/group in cosmos-sdk v0.47 or higher.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned