> Casual observation is what happens when the identifier can be shown in > network traffic, logs, etc. There, the properties vary depending on how > the hash is constructed. If H = hash(public-key), then the identifier is > static, and the privacy properties are just the same as publishing the > public key -- which means, mostly terrible, as EKR said. On the other > hand, if H = > hash(public-key|something-that-changes-for-every-session-and-is-hard-to-predict), > then the properties are similar to privacy preserving IPv6 addresses. Just note how much better the above is than what we have today with both provider-assigned and provider-independent address allocations. > Many of the scenarios seem to require proof-of-ownership, as in "proving > that the device can legitimately use the ID by demonstrating ownership > of the public key behind the ID". In that case, you are effectively > publishing the public key. If the public key is static and permanent, A single instance of a public-key is static but you don’t always have to use one identifier, and thereby don’t need to use one key-pair. And with a locator/ID separated architecture, you have flexibility to not require permanent addresses. > that is a pretty strong identifier with terrible privacy properties. On > the other hand, if you can pick a new public key for every session, then > the privacy properties are reasonable. See Bitcoin example. Dino