1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account.
2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability.
Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.
1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account.
2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability.
Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.