by Alex Ortiz
I’ve always believed that life strongly rewards curiosity: humans are optimized for constant learning and growth in order to socialize and solve problems. One of the reasons blockchain technology is so fascinating to me is that it’s so hard and has so many evolving unknowns. When I joined lifeID, I did so in part because decentralized identity promises to be connective tissue across many blockchain use cases and there is still so much to learn. As Chief Blockchain Evangelist, I wear three main hats:
- finding ecosystem partners who will build on our open-source identity platform,
- listening to what’s happening in the industry to inform our team’s future design and product decisions, and
- educating the market about our philosophy on identity on the blockchain and what it means to own and manage your digital self-sovereign identity
That means I get to learn, as I go, about the world of decentralized identifiers, decentralized public key infrastructure, decentralized key management systems, verifiable credentials / claims, zero-knowledge proofs, and many other exciting, applied identity concepts. To say this is both difficult and fun is an understatement, but the fact that I actually get to share my learnings with the world is just plain cool.
Last week, I marked up a whiteboard to map some new ideas for myself, specifically around what a decentralized identifier (DID) is. I was trying to assimilate some of what I’d learned in the preceding few days after attending the KNOW ID 2018 identity conference in Washington, DC, listening to panelists, talking to various identity professionals, and reading through the W3C’s DID Spec. The whiteboarding exercise was about locating and contextualizing some of the basic concepts I’d picked up, and in this first Learning Together Series blog, I’d like to share some of what clicked for me that morning and what I’ve been thinking about since.
A New Class of Identifier
A DID (pronounced as “did” by some and “dee I dee” by others) stands for decentralized identifier. It looks like this:
did:life:abc123
Why it’s formatted that way, I’ll return to at some later time. What job each of those three namestrings has, I’ll also return to at a later time. (The third string in the DID is actually far longer, with no current upper limit, yet that may change in the future).
As I was whiteboarding that morning, I found it resonant that a DID is a machine-friendly identifier. It’s machine-friendly because it’s intended to be read by computers and machines, as opposed to humans. Once decentralized identifiers become commonplace over the coming years, computers and machines will interact with those identifiers in a variety of ways. Up to that point, I hadn’t considered that names, addresses, website URLs, email addresses, Twitter handles, or, for that matter, room numbers in office buildings, aisle numbers in grocery stores, and terminal or gate numbers in airports are all examples of human-friendly identifiers. These are simply ways of finding specific persons or places in order to interact with them in some specific way, based on the type of identifier. For example, we use names to locate, address, or reference particular individuals. We use addresses to navigate to locations or send mail to others or have items we buy sent to ourselves. And we use website URLs to literally locate resources online — LinkedIn, Medium, or any of the other 200 million active websites in the world. So identifiers make it easy for humans to interact with other humans and coordinate the exchange of information, goods, or work; intriguingly, the context of exchange shifts as technology advances (e.g., phone numbers can now be used to call, text, or even send money to someone).
In the coming world of blockchain-based identity, computers and machines will need machine-friendly identifiers to carry out important new functions such as enabling sovereign identity management, managing user public keys, and accessing smart contracts with instructions regarding the creation, revocation, update, or deletion of those identifiers. In my example DID (did:life:abc123), the third namestring (‘abc123’) functions as the location of the smart contract tied to the owner of the DID. The owner, by definition, controls the private keys needed to prove ownership of and control their DID at will. In the lifeID model of blockchain-based identity, the smart contract associated with the DID will live on a blockchain, and computers on a ledger or other network will need to know where to locate the contract (i.e., which blockchain and where) in order to perform the work requested by the owning entity. This entity, by the way, can be a human user, a company/organization, or even an individual IoT device. A DID represents a unique digital relationship between any combination of two users, organizations, or devices.
In the next article in this series, I’ll explore what I’ve learned about each of the three namestrings — the DID prefix, the DID method / schema, and the smart contract address — in greater detail.
Thanks for reading my first article in our Learning Together Series, and I look forward to your questions and comments!
You can also follow me on LinkedIn, where I’m quite active: linkedin.com/in/alexoblockchain/.
Be sure to follow our team on Twitter at @lifeid_io as well.
