Skip to main content

Long long ago when people used “pay-phones” and listened to the music of our modems connecting to the internet, I was part of a small and curious community. We called ourselves “hackers” and enjoyed learning how this internet thing worked. We took things apart and ran a prank or two; no ransomware for us! Back then, hacking was about learning and exploring. The community was a fascinating place filled with brilliant people. But Fear of the Man meant that people in the community could not trust each other with their real-world identities.

So, how can a community work together and moderate itself without that trust? The answer was simple: we had anonymous identities that we used consistently.

I probably interacted with hundreds of people over that time, but I never knowingly met any of them. We never used our real names; we used aliases. To keep track of each other, each of us used the same alias consistently. Sometimes we’d maintain multiple aliases and have different identities in different places. We’d need to protect against impersonation because our aliases were who we were. A hacker’s alias could be interrogated and hackers could build a reputation. Reputation was earned “on the job,” by being the first to reverse engineering this or the first to gain access to that.

A solid reputation would get you invited to smaller groups where we discussed more sensitive topics. These smaller circles would have strict rules that could be enforced – add/remove members, for example. Groups would be formed spontaneously, and self-organize. We had a community that was learning, teaching, and most importantly: producing (by our own definition of producing), even while everyone hid their true identity.

Same with email addresses. Is bill.gates@yahoo.com the same person as bill.gates@microsoft.com? These identities are not portable and you don’t control them. Still, today, our digital identity is largely bound to an email address on a mail server you might not run, a specific domain over which you have only partial control. If the provider, for whatever reason, ever decides to close your account, it’s game over.

Let’s imagine something better than today’s email/facebook/twitter handle-as-identity and write some requirements:

  1. Decentralization. A user can create and manage their own digital identity without a centralized authority.
  2. User Control, Privacy. A user controls who has access to their digital identity.
  3. Security. A user can prove ownership of the digital identity and use it to authenticate to various services and applications.
    This sounds great, right? However, something is missing. If I can create my own digital identity, verify what I created, and share it freely – who is it to say it is true? For example, how can I prove to you that I am indeed Alex who works at YeshID? Currently, the best I can do is send an email from @yeshid.com domain. By you trusting that yeshid.com wasn’t compromised (or spoofed) and is indeed owned by the company, you would trust that an email from me, from an address issued by YeshID the company (alex@), is proof I work at YeshID. It’s not much, but better than nothing.To achieve this functionality with the digital identity above, we need to add some more requirements:
  4. Issuance & Revocation. An issuer (e.g. YeshID) can issue and revoke credentials to a holder (e.g. Alex).
  5. Verifiability. Upon presentation of the above credential by the holder, the receiver can verify the authenticity (e.g. Alex claiming to work for YeshID, and the receiver can verify it by asking the issuer if that’s true or not)

So, with these requirements, I would be able to receive a digital document from YeshID that verifies I work for YeshID. I have complete control over who I share this information with, and I do not depend on the issuer for doing that – so I have privacy and decentralization. When I try to use it to log into the company bank, for example, the bank can ask the credential issuer – YeshID – if the credential is still valid or not and grant me access or not based on the credential’s validity, and maybe my role, or other parameters it needs.

Does that sound too good to be true? Too futuristic? It’s not! You might have encountered some of this functionality if you ever received and used a digital COVID pass (in the UK, sorry, USA.) The whole solution is built upon Decentralized Identifiers (DID) and Verifiable Credentials (VC), a couple of new standards that have undergone extensive reviews and are being recommended by W3C – “The World Wide Web Consortium (W3C) [is] an international community that develops open standards to ensure the long-term growth of the Web.”

In the near future, when you go to my LinkedIn profile, you will see a digital credential that proves I work at YeshID. You might even be able to use that link to request more information, such as how to get in touch with me. You might also find that my YeshID persona is linked to another persona called Alex Vaystikh, decoupling the professional persona from the private person, and you will be able to use these documents to ensure you’re talking to the intended person. In the UK, health professionals in the NHS will use VCs to improve onboarding and permission management. In Europe, thanks to EBSI, you might see the advantages of verifiable credentials when moving between borders or notarizing documents. And maybe somewhere else entirely, you will find some self-issued digital identity that misses BitchX and talks complete nonsense, anonymously and securely. All of these are powered by DIDs and VCs.

In YeshID, we are leveraging the latest technologies to make identity and access management simple and secure, both for companies, employees, and beyond.

If you’re an admin responsible for the identity, access management, on-and-offboarding employees, compliance, and license provisioning, and you hate how repetitive and time-consuming it is both for you and your team, then email us at “iam” + “@” + yeshid.com, or ping Dana or me by LinkedIn.

If you want to build with us, we’re hiring! Check out our careers.