-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of SSL certificate types (OV/EV) for validation and highlighting of domain-based handles #3024
Comments
Your screenshots are really old This is the current situation, as the wider industry trend is to not display positive UI indicators for "secure", rather to be neutral and, instead, display negative UI features for insecure things. Given that the ev specific badge is no longer reflected in browsers, and hasn't been since 2019 they are treated the same as a domain validated certificate in browsers, so why would Bluesky want to start bringing back the old way of treating them? The only real use for EV now is for codesigning on Windows, where Defender/Smartscreen will provide a greater weight to them when it comes to unknown/untrusted code warnings. More reading |
@blowdart Good note about these certificate types no longer being displayed by the browser, but i think it doesn't really matter for a theoretical use within Bluesky. it's not about displaying the certificate per user profile in the address bar of a browser - I attached the screenshot to clarify which certificates I mean. It's about clarifying the question of how you can securely verify a person or a company in a federalized open network like the ATProtocol without having a central authority that defines who is authentic. Of course, the question arises if the OV and EV certificates will disappear in the future and not be issued anymore. However, if this is not the case, the benefit remains the same, as it allows differentiating whether a user simply has a fancy domain or whether the person or company has actually been verified as real by a trusted third party source. As an example, I can also buy JoeBiden.rs currently for 22.66$ and then use this as BlueSky handle. |
This falls to what a DID is. https://www.w3.org/TR/did-core/ doesn't require a website to back a did and thus doesn't require TLS and a certificate at all. I see your point about not requiring a central authority, but you're making CAs a semi-centralized authority instead, and they have been bad at that. It feels, to me, a step back to the bad old days where certificates had costs and weren't issued to individuals at all. |
Yeah, you can buy joebiden.rs and use it as your bluesky handle, but nobody is going to believe that the real Joe Biden would use an rs domain. The whole point of using domains as a handle is that verification is free and everyone can get verified. Also, for quite a few public figures, it's going to be very easy to verify, just spend 5 seconds on Google and check if the domain in their handle is their actual domain or a scam site. Or just check the whois records. Just like we've verified the authenticity of websites since the beginning of the internet. Putting a "verified" checkmark on EV certificates would mean that A) Bluesky staff would need to manually verify the name on your cert and compare it with your identity and B) it would add a ton of costs to getting such a validation, just like on Twitter / X with that stupid blue or yellow checkmark. You'd just be paying 100+$ a year to a CA for an EV certificate that's not really used for anything other than Bluesky. I don't think EV certs are going to disappear, there's always going to be companies who want such a thing. But browsers give them less and less credit, and while it may be useful for stuff like code signing certificates, I don't think it's going to be useful for a social media account. |
The only valid argument that can actually speak against this is what @blowdart notes, that this would turn a CA into a “semi-centralized authority instead” and the fact that DIDs by definition should work without a web server / website and can be resolved via DNS alone (Although we also allow .well-known as verification of the domain, which is very much a requirement for a website). |
Am I misunderstanding how EV validation works? As far as I know, EV only verifies who owns a domain. Anyone who owns a domain can get an EV cert proving that they own said domain. But that doesn't mean that |
@Leseratte10 What you are talking about is a DV certificate (Domain Validation), this is only used to confirm that the applicant is in possession of the domain and says nothing about the person behind it. An EV certificate (Extended Validation) and OV certificate (Organization Validation) on the other hand (which is what my feature request is about) is issued by a trustworthy certificate authority, which verifies the authenticity by means of various documents and ensures that it is the person or organization it claims to be. In short: Only those who can present all the necessary documents and go through the validation process of the CAs will be able to obtain such a certificate for a long time. This gives the responsibility for Bluesky to check whether a person is really the person or a company is really the company to a third authority that has made this its mission and is known for it. Ultimately, this is an absolutely optional thing, but it can ensure that people with less understanding of DIDs, domains etc. can also be sure on Bluesky whether they are reading the news of a confirmed journalist, politician and co. |
I know about the difference between DV and EV certs. Lets say my real name is John Doe. Then I can go to a registrar, register the domain mlcrosoft.com, and then go to a CA, give them my documents and ID to prove I'm really John Doe and that I really own mlcrosoft.com. Then I get an EV certificate for mlcrosoft.com. And an old browser would have displayed that as "mlcrosoft.com, owned by John Doe". Then I use said EV-validated certificate to change my Bluesky handle to "john.mlcrosoft.com" (which I can, since my real name is John Doe and I have an EV cert for my domain mlcrosoft.com), and people are going to think I am a real Microsoft employee. All an EV cert does is link a real, verified person's real identity to a domain name. It doesn't mean that that person is affiliated with the company that's claimed in that domain name. Bluesky would still need to manually prove if the person John Doe, who has an EV cert proving that A) they are John Doe and B) they own mlcrosoft.com; is affiliated with Microsoft. A CA does not do that (well maybe they will for high-security targets like mlcrosoft.com or even refuse to issue a cert at all due to phishing concerns, but that definitely doesn't apply in general). Or, a more real example. Bluesky uses the domains "bsky.social" and "bsky.app". Two fairly uncommon domain TLDs already. Bsky employees use "bsky.team", an even more uncommon TLD. I, John Doe, can then just decide to buy bsky.com or bsky.net or whatever, then get an EV certificate that certifies with my real name that I own this domain, and then I can make a handle like "john.team.bsky.com" to make people think I'm a bluesky employee with a blue checkmark. EV certs don't help prevent that. |
I'm really impressed with the implementation of domain-based handles on Bluesky as an open and more secure alternative to the old Twitter Bluecheck.
My suggestion is to use the different SSL certificate types (Organization Validated - OV, Extended Validation - EV) to better represent the trustworthiness of a domain in the context of a Bluesky profile. This could not only help against phishing-like domains (e.g. https://paypaI.com/, where a capital 'i' is used instead of an 'L'), but also clarify the authenticity of official institutions, companies or public persons.
Such a feature could help to strengthen trust in domain-based handles, protect users from phishing attempts and make the authenticity of companies and public figures clearer.
The text was updated successfully, but these errors were encountered: