Well DID spec doesn't tell us to put identity or related keys in public. DIDs coupled with the VC model (https://www.w3.org/TR/vc-data-model/) allows identity credentials issued by any "trusted" issuer to be validated. Here trusted means whoever the user trusts, be it government or big tech or anything else.
The issue is not other identity information in the DID, it is the identifier mandate itself is antithetical to privacy.
Having a global identifier as you go about the internet means that parties can correlate and share information about you.
Trying to solve that by isolation (using a DID per party you want to interact with) negative affects their usability and privacy properties with verifiable credentials.
Then there ought to be a way tp cheaply produce verified but ephemeral identities, which may be discarded after a particular transaction.
User: I want to use this site.
Site: we need your trusted identity.
User: Trusted Third Party, please make an anonymous identity for me.
TTP: I know you, user; here's your new identity.
User: Site, look here, TTP which you trust says I'm legit.
Site: OK, transaction completed. '
User: (destroys the identity's private key.)
It's not very different from TLS certificates, or OAuth tokens, or even ephemeral credit card numbers. The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
> The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
Aye, there's the rub. What's to stop most sites from only allowing Google/Facebook as the Trusted Third Party? And you also need to worry about security breaches, or one company quietly buying up all the independents, or governments legislating in back doors, or every service you use ganging up behind the scenes to try and collate your "anonymous" public keys back into a single identity.
Don't get me wrong, I do think there's a way forward, but it's not going to be easy.
It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
The idea that TTP certifies User against particular requirements of Site, and gives User an identity which User can give to Site. TTP keeps the "real" identity of the user hidden from Site, replacing it with a temporary identity.
TTP does not givel Site anything; User shares the temporary identity with Site. Then Site can check the identity, cryprographically and/or by asking TTP directly.
The identity should also be checked by a challenge-response protocol between Site and User, so that stealing it from User would be pointless. E.g. User keeps the private key and Site receives the public key, and Site asks to encrypt a random string, then tries to decrypt it.
> It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
How does the TTP know that the user isn't a spammer? Is there a backchannel for reidentifying users in case of abuse allegations? Does the TTP just refuse to issue credentials on behalf of the same user very frequently?
That's incorrect. DID make use of pubkey cryptography to create a new identifier for every entity one operates with... this argument is based on imagination
Where did you get the idea 'global' from?
Have you seen Peer DIDs? Most specifications advise you to create limited purpose identities. Use a widely known one when it suits you, like a LinkedIn profile, or Twitter page.
Exactly. DIDs don't need to be global identifiers. I can create multiple DIDs. Maybe one of them gets issued an identity VC. When required I may use that DID to prove my identity, otherwise use the other DIDs.
