Given usernames-as-domains, is there a reason to not just piggyback this on the X.509 web of trust?<p>After all, we already have an established and highly-monitored set of sibling "trust roots" — we call them Certificate Authorities.<p>And we already have an identity-validation system coupled onto X.509 FQDN-as-CN (i.e. TLS) certificates — certificate validation levels.<p>BlueSky could just:<p>1. require a domain username for verification;<p>2. require that the domain presents an Organization Validated (OV) cert for verification as a "public individual" (i.e. the kind with a "personal brand" — which usually implies "worth registering as an LLC");<p>3. require that the domain presents an Extended Validation (EV) cert for verification as a corporation.<p>...and the whole problem of identity validation becomes outsourced, <i>and federated, and decentralized</i>. (Federated because multiple sibling CAs; decentralized because every computer administrator gets to decide for themselves which CAs their machine should trust.)<p>---<p>A rebuttal might be that "EV certs can't be used for this, because EV certs are too expensive, take too long to get, and don't integrate well with automatic per-subdomain DV cert issuance via ACME."<p>But (IMHO) that's not a problem to be worked around; that's a problem to be fixed. Why leave a broken generalized web-of-trust infrastructure sitting there unused?<p>If an online casino can KYC/AML you in two minutes with a passport scan and a 3D camera photo, it shouldn't be impossible to do for OV+EV validation what we did for DV validation with ACME. (Ideally in such a way that you can do the interactive process once, receiving not a cert, but some kind of collateral; and then, later on, any ACME server should accept that collateral during an interactive domain ownership probe, to upgrade the DV cert it's issuing you into an OV/EV cert.)<p>---<p>The other neat thing about this approach is that, in a "fat" native BlueSky app (i.e. not just an Electron wrapper), the app wouldn't have to trust <i>the BlueSky service</i> to say who's verified. The app could TLS-validate each domain username <i>itself</i>, to compute the appropriate badge for that user — just as a web browser does when you visit a website. And it would presumably use <i>your machine's</i> OS TLS CA store for that validation, just as (some) browsers do.