ERC-1078: Universal Login/Registration Using ENS Subdomains [DRAFT]

🚧 Stagnant Standards Track: ERC

Table of Contents

• Abstract

• Overview

  • Implementation
  • Conclusion & Future Improvements
  • References
• Copyright

Abstract

This proposal introduces a minimal Ethereum-native solution to replace traditional registration/login design patterns. It eliminates passwords, private key backups, and seed phrase inputs. From the user’s perspective, it mimics familiar two-factor authentication (without centralized servers), while requiring developers to rethink Ethereum transactions for DApps.

Overview

A user’s unique identifier is a contract implementing both Identity and Executable Signed Messages ERCs. Users provide an ENS name pointing to this contract, not the address directly. These contracts are indirectly controlled by private keys, which sign intent messages later deployed by third parties (or decentralized networks).

Login Process:

1) Request ENS Name

The app prompts the user for their ENS name. If unregistered, offer subdomain creation.
UX Note: Validate names efficiently—avoid duplicate inputs and guide users gracefully (e.g., "Login or create?").

👉 Learn more about ENS integration

2.a) Create New Identity

For new users:

1. Generate and securely store a local private key.
2. Deploy an ERC720/ERC1077-compatible identity contract.
3. Register the key as the sole admin key.
4. Transfer subdomain ownership to the contract.
5. (Optional) Add a recovery method.

Gas Optimization: Pre-deploy contracts with variables set to 0xFF...FF for cost efficiency.

2.b) Connect Existing Identity

Apps request permission levels:

• Manager: Modify identity (e.g., add/remove keys).
• Action: Move funds/assets.
• Encryption: Sign off-chain messages (e.g., chat, games).

Steps:

1. Generate a local private key.
2. Query ENS for the identity address.
3. Create addKey(PUBLIC_KEY, LEVEL) bytecode.
4. Broadcast via Whisper or P2P networks.
5. Fallback to EIP-681 QR codes if needed.

Example EIP-681 URL:
ethereum:bob.example.eth?function=addKey(address='0xdeadbeef...',uint=1)

3) Transaction Requests

For on-chain actions:

1. Determine to, from, value, and data.
2. Verify required permission level (Manager/Action).
3. Check requiredSignatures(uint level).
4. Estimate gasLimit + 100k buffer.
5. Set gasToken (0 for ETH) and gasPrice.
6. Sign and deploy via executeSigned.

For multi-sig transactions, broadcast via Whisper until nodes collect all signatures.

Implementation

No live examples yet, but developer interest is high. Updates will follow adoption.

Conclusion & Future Improvements

Enables lightweight apps with device-locked keys for seamless interactions. Future work includes standardizing decentralized messaging and open-source node tools.

👉 Explore Ethereum identity solutions

References

• Universal Logins Talk at Toronto UX Unconf

Copyright

CC0: Waiver.

Citation
Alex Van de Sande, "ERC-1078: Universal Login/Registration Using ENS Subdomains [DRAFT]," Ethereum Improvement Proposals, no. 1078, May 2018. [Online]. Available: https://eips.ethereum.org/EIPS/eip-1078.

### Keywords:  
- Ethereum ENS  
- Universal Login  
- ERC-1078  
- Identity Contract  
- Executable Signed Messages  
- Decentralized Authentication  
- Gas Optimization  

### FAQ  

**Q: How does ERC-1078 improve user experience?**  
A: It removes passwords and seed phrases, relying on ENS names and local key storage for seamless logins.  

**Q: Can apps charge for identity creation?**  
A: Yes—developers may impose fees or anti-sybil measures (e.g., CAPTCHA, PoW) for registrations.  

**Q: What happens if a private key is lost?**  
A: Recovery methods (optional) can restore access, or new keys replace lost ones without asset risk.  

**Q: Are off-chain signed messages secure?**  
A: Yes—contracts verify sender validity, and keys can be revoked if compromised.  

**Q: How multi-sig transactions work?**  
A: Apps collect signatures via Whisper/P2P networks until nodes deploy the transaction.  

**Q: Is gas paid by the app or user?**