The core of the identity problem is, “how can someone ban you personally without being able to identify you?”, and so far as I know, “a trusted third-party checks your identity and issues you an identifier” is the best we’ve got - but of course those identifiers can be enriched, so you end up needing a single centralized third-party that can issue identities and also honor bans for “the individual behind identity X” from specific sites by site request, while being audit-proven to actually enforce those bans upon me regardless of how many anonymous identities I choose to generate and use. (If you don’t run this as a monopoly, either they all pool their
user-operator banned identities lists to prevent ban evasion, which will eventually leak, or they will be compelled to someday later down the road when they lose the inevitable monopoly lawsuits.)
It’s not difficult to solve this problem — the database schema and queries are dead simple! — it’s just exceedingly difficult to succeed if you're not a passport-issuing entity or an authorized monopoly of such.
I wrestle with this by just separating this concern.
In the model I described, the trust anchor would be the govt, so basically a centralized model like domain certs. This resolves the issues you list off, but brings others: what if the trust anchor isn't trustworthy and starts forging identities?
The alternative to that would then be web of trust stuff. But this is why I consider this to be a separate problem. If the core protocol could be laid out and standardized at least, then layering on another that makes this choice between centralized vs web of trust could be done separately.
It’s not difficult to solve this problem — the database schema and queries are dead simple! — it’s just exceedingly difficult to succeed if you're not a passport-issuing entity or an authorized monopoly of such.