We need a service like a DNS, where a bitcoin client makes a request for the mail address "
name@domain.com" and the service responses the Bitcoin address.
But the response must be signed or something like that, to avoid (man-in-the-middle)attacks of the service.
works like namecoin?
No, i mean a centralized service.
You sign up, sign in, insert your address and sign the address.
But you need a trusted service.
Only a thought experiment from me... not yet thoroughly thought through
The service need not to be trusted if you use some kind of crypto... The best way as I said would be to use PGP/GPG with included Bitcoin address in the note field along with your email or just signing the current BTC address with you GPG key and posting the clearsign text on the 3rd party website where users can view it and optionally check in their own gpg client.
EDIT: It would be nice if you could do it all with just Bitcoin signatures, but that's impossible for this use-case (you would be signing e-mail address with an "untrusted" Bitcoin key pair).
EDIT2: Also note that all previously created clearsigned addresses can be securely revoked as long as you keep your private key private, which is good in case your wallet gets compromised (but not your GPG private key; but there's also way to create GPG revocation certificate and broadcast it to keyservers when you private key gets compromised and it invalidates everything signed with the now compromised key).
I'll post a proper announcement later but I've been working on a service a bit like this. I'm planning on starting with a version that runs on Twitter for Twitter usernames, then doing email, then other kinds of identity. (My original motivation was virtual world avatars for OpenSim, which I'd also like to do.)
The way I see it, the problem is split into two parts, which could conceivably be run by different people:
1) Confirming identity-address pairs (eg this address belongs to this email) and signing them with the identity-confirmer's GPG certificate. This is done either by sending a confirmation message (email) or by trusting the information given by a system's API (Twitter). Traditionally this is the kind of thing that webs of trust can help with, and that may turn out to be the ultimate solution, but I think we get something usable quicker with just a few trusted parties. If somebody turns out not to be trustworthy we can stop serving data they've signed.
2) Storing and serving the GPG-signed identity-address pairs, and making them available through an API to anyone who knows the identity side (eg the email address). People using the API would check the signature of the data they fetched against a list of known good identity-confirmers, which should protect against the web server serving the data getting hacked.
Ideally I'd envisage this data being shared by at least 2 or 3 different people or organizations which all support the same API, so that you could develop applications that use it and be reasonably confident that it won't suddenly disappear. In a world full of technical people the data would all be entirely public, but in the real world that we sadly inhabit non-technical people generally have reservations about the way their email addresses are shared, so in practice I think this is also better done by a smallish number of independent people or organizations that agree to try hard not to leak it. Email addresses can be stored hashed, but that can be brute-forced in a lot of cases as they're fairly predictable. If somebody ends up accidentally leaking the data, that's bad, but not devastating.
