Email Based Account #15
Conversation
| @@ -70,4 +70,4 @@ assignees: "" | |||
|
|
|||
| ## Support Needed | |||
|
|
|||
| **What kind of support or information do you need to resolve this issue?** | |||
| **What kind of support or information do you need to resolve this issue?** | |||
There was a problem hiding this comment.
could you remove this deletion/addition from your PR
There was a problem hiding this comment.
i am not sure what this deletion/ addition is from the PR. Just to be sure, i added the template afresh from ab2 repo and pushed it again.
Is it what you are looking for?
| - create an account for an email address [email protected] based on .eml file: | ||
| - verify header is valid using dkim signature verification | ||
| - check sender is '[email protected]' | ||
| - (additional check) check if subject contains a specific random string shown in UI |
email_based_account/README.md
Outdated
| - verify header is valid using dkim signature verification | ||
| - check sender is '[email protected]' | ||
| - (additional check) check if subject contains a specific random string shown in UI | ||
| - hash email into pedersen 2 hash (?), convert into field element type Fr and use it as encryption key in getSchnorrAccount(..) function and show the accoung wallet in UI (user can sign tx from this wallet as long as they know the signing key) |
There was a problem hiding this comment.
Does this mean a hash of non-private information would be used as private key? I might be missing something though
There was a problem hiding this comment.
You are right. That is exactly what is happening.
I mean I want to use a private key that is deterministic and derived from the email address (the goal is to avoid seed phrases/ hex entirely). I can use a salt/ randomness I guess from a password that the user creates, along with the email ID for the private key. to solve the (obvious) problem that you highlighted. Account recovery may become a problem if user forgets the password, but, maybe I can solve that problem later on.
email_based_account/README.md
Outdated
| Consider including: | ||
|
|
||
| - How does your project leverage Aztec's unique features? (programmable cryptography, private/public state, etc.) | ||
| - What is the potential real-world impact of your project? |
There was a problem hiding this comment.
Would be good to know more about these
There was a problem hiding this comment.
I added those points in my readme reproduced below:
This project uses zkemail.nr library for email verification on the user's device. The email ID is kept private and within the user's device.
While not directly within scope of AB2, the wallet is being built only because
it allows fully private state and activities, most importantly:
private transfers of stablecoins and eth
assets can stay fully private for user, as absolutely esstial for card games
account abstraction features that make possible
user friendly encryption and signing key namely, email based hash for private key and Face ID for signing key
email ID based token transfer (???)
transaction rules like 'allow only transactions below $100 / day by email(???)'
allow session ID based transaction approval
fee abstraction features: -allow for wallet provider to pay gas (needed for activities like card games)
What is the potential real-world impact of this project?
onboard web2 users using familiar account creation and signing methods like email ID and face ID -( there are other features relevant for web2 users in wallet but that are not directly within scope of AB2)
|
please add a gitignore and exclude |
|
Added .gitignore file to exclude node_modules and build artefacts |
My project creates an email based schnorr account in a aztec wallet (which was built in alpha build 1). User enters email ID and uploads .eml file. We use zkemail.nr to verify 2048b dkim signature, match sender email ID and signature key to create schnorr account. We hash sha256 the email ID into a encryption key for schnorr account.