Hans Gerwitz writes to tell me about a proposal he calls PersonCode. If I understand this correctly, the idea is to run a person's e-mail address through a secure hash function, and use the result to correlate the same user's accounts on different services.

He writes:

What I want can be described by a simple scenario: I enable "publish my PersonCode" on my plazes profile. Later, I login to Yelp, who knows my email address, and they make a request to plazes asking for the location of PersonCode 1e2998da88a2c4fe1eef13c013bffbf3bca2c3a8. If plazes had never met me, they wouldn't have learned [my] email address; however, since they have they can respond and Yelp can use the answer to offer a "near here" search option.

Just to clarify, the use case he's describing is to correlate data from two services in order to allow some kind of mash-up of the data, without having to set up a full identity infrastructure.

After a bit of back and forth by e-mail, I responded to him with:

The biggest question in my mind about proposals such as yours is whether they are standalone things, or just features of something larger. I come down on "something larger". (you may or may not agree)

If it is something larger, however, the question is, is the approach taken the right one given that a number of other things will be in the same package that is adopted as the "something larger". For example, if the "something larger" also contained URL-based identity (just assuming this for a second), then chances are that correlation will be done by (authenticated) URL rather than by schemes such as the one that you are proposing, because the same problem can be solved more securely etc. etc. through the availability of other technology in the same package, such as public keys or shared secrets.

But of course, nobody knows for sure so far ... what's certainly good is that innovation is happening thanks to people like yourself.