Discussion for Add EIP: Account Recovery by OIDC by dongshu2013 · Pull Request #7743 · ethereum/EIPs · GitHub
The purpose of the EIP is to standardize the interface for a new model which use OpenID ZK Verification as the recovery mechanism for AA account.
This is a very interesting proposal, and I think it could be a very powerful primitive. It’s great to see it being published as an EIP.
If I have one question, it’s whether there are known requirements for creating a proof of a HWT, e.g. what cryptographic schemes need to be supported etc. Is there reference documentation for this? For example, is there an implicit dependency on a zk implementation of say the OIDC spec?
@orbmis The implementation is open to all the ZK algorithms. Right now we mainly focuses on the Nova implementation: GitHub - OpenID3/zk-jwt: the library to generate zk proof for JWT
This is really interesting. I’m curious about the vision for the guardians.
One may set multiple OIDC identities(e.g. Google Account, Facebook Account) as guardians to minimize the centralization risk introduced by the identity provider.
Does this imply the ability to roll up multiple JWT proofs into a single proof? For example, if I had a wallet where I wanted to set up 3 guardians and require a 2/3 threshold of valid JWTs as a precondition for recovery, is that feasible with this approach? It seems critical to enforce a minimum of 2 JWT signatures for this to effectively minimize centralization risk, but I’m not sure if this is one of your design goals.
Supporting the mode with multiple OpenID to recover one account is one of our goals, not only to ensure the recovery is decentralized enough but also to provide better security. The way to achieve this is quite flexible though. We can either aggregate the proof off-chain or we can simply implement the multi-sig logic on-chain and do verification for each proof separately.
Very glad to see this as an EIP on Ethereum! However, this proposal is not sufficiently descriptive… Are there more updates expected?
Two questions:
How is the address associated with an OpenID account derived? e.g., AFAICT, to prevent phishing, the address needs to be associated both with the user (by anchoring to, say, the sub field) and the OAuth application (by anchoring to the aud field)
The EIP talks about privacy, but the TXN signature seems to include the JWT signature which, when verified against the JWT header & payload would leak the identity of the user.
The EIP mentions “Privacy will be guaranteed as the connection between Web2 identity and the Web3 account will be hidden.” But the details are missing: i.e., what is the ZK relation? (e.g., see an example here)