In the past few articles, we’ve had to define what are the traditional or normal occurrences in order to define the new subject matter. I haven’t discovered a better way to start yet, so this one starts the same way.
Traditional identifiers
Society is filled with identifiers.
Right from birth, we are given names, passport numbers, certificates to identify ourselves. We grow up and interact with the world using email addresses, social media usernames, and earn ourselves driving licenses. The cashier scans the barcodes and RFIDs on our purchases. All these tags are called identifiers; they help another person identify a person, a matter, or anything unique really.
In traditional identifiers, these names or string of numbers are created by a trusted entity, person, authority or organisation. They have the ability to create, destroy, and amend these identifiers.
Once these entities cease to exist, these identifiers too cease to exist or provide any more meaning (single point of failure). A consequence of that is that the subject matter would also lose their identity too.
DIDs: Decentralised Identifiers
DIDs are a new form of identifiers that does not rely on any centralised registration authority.
These DIDs can be generated using globally-accepted standards of cryptographic issuance. These same identifiers can also be verified cryptographically.
Since both the issuance and verification of the identifiers can be done cryptographically, there is no need for a trusted third party to be involved in the issuance, and maintenance of the identifiers.
Since no entities are responsible for overseeing the management of the identifiers, it is important for DIDs to be interoperable. A useful DID is one that is network-independent, and is able to work with multiple tools and standards globally.
Example of DIDs replacing traditional identifiers
Let’s imagine that a student has passed all his exams, and has finally graduated from University. Upon graduation, the University issues him a Certificate.
To ensure that the Certificate is authentic, they issue it with a watermark, imprint or a seal.
The verifier, in this case, probably an employer who is considering hiring the graduate, would need to assess if he actually did graduate from the University, and that grades reflected on the transcript are real.
The employer can do 2 things: check the Certificate’s seal as proof of authenticity, or call up the University to do a background check. To check on the certificate’s seal, employers may need to request for original copies of the certificate. Besides the obvious time-and resource-consuming nature of this process (imagine screening 500 candidates a day), these verification methods are subject to fraud and human errors.
The graduate may have also completed a Masters programme with another University, and hence received another Certificate issued in a different format.
For administrative ease, employers rely on the digital document (such as PDF) as proof. This method, as we know, is highly flawed. Anyone can forge a PDF document. But not everyone can tell a fake from a real document.
The graduate also has no choice but to trust that the University is safeguarding his personal information properly. The graduate also has to trust that his future Employer, upon receiving his transcripts, are not sharing them without his permission.
What if DIDs can help with this process?
Instead of each University issuing their own Certificates, what if they issue them in a certain globally-accepted digital standard?
The Universities can publish their public keys on a public ledger (like a blockchain), so that employers can refer to those keys to verify the certificates.
The graduate will keep all those different certificates he has been issued with in a digital wallet. He can choose to share different certificates to different verifiers at his own discretion.
By replacing physical certificates with DIDs…
Employers can:
- Ensure that the certificate content is real, have not been tampered with
- Ensure that the certificate was indeed issued by the claimed University
- Do away with manual verification
- Ensure 100% compliance instead of doing random testing, hence allowing for scalability
University can do away with:
- Printing a seal or issue a physical cert (unless they want to for aesthetic purposes)
- The burden of managing database of certificates for all their students (legal risk)
Graduates can:
- Secure a digital print of their own Certificate that can be verified independently
- Ensure that University cannot abuse the information to unknown parties without his consent, or mismanage them, as the University no longer holds those information
- Ensure that Employers cannot abuse the information to unknown parties without his consent, or mismanages them, as he does not need to send an offline copy of the certificate to the local machines and portals of the employer. Employers are only allowed to verify the document and content authenticity, without storing the information on the document.
This all sounds too good to be true.
What are these ‘globally-accepted digital standards’ exactly?
Uniform Resource Identifier (URI)
A DID is ultimately, a type of URI.
By definition, a URI (Uniform Resource Identifier) is a standardised string of characters used to identify any resources on the internet.
This is a syntax of a URI from this tutorial:
scheme:[//authority]path[?query][#fragment]foo://example.com:8042/over/there?name=ferret#nose\_/ \______________/\_________/ \_________/ \__/| | | | |scheme authority path query fragment
- Scheme: HTTP, HTTPS, mailto, file, FTP, etc
- Authority (optional): present after //
- Path: sequence of segments
- Query (optional): present after ?
- Fragment (optional): a string of data
Examples of URIs:
1. mailto:hey.Doe@example.com
2. http://www.ietf.org/rfc/rfc2396.txt
3. ldap://[2001:db8::7]/c=GB?objectClass?one
4. tel:+1-816-555-1212
5. telnet://192.0.2.16:80/Components of a DID
Following the URI syntax, there are 3 components to a DID:
- scheme: did
- DID Method: specifies how the DID is created, can be made in reference to a ledger that contains the public keys required to resolve this DID.
- DID Method Specific String: the unique identifier or keys
An example of DID Method can be a public ledger such as Bitcoin (did:btcr) or Ethereum (did:ethr). These ledgers contain the public keys that verifiers can use to verify the DID.
A DID is really just that string of numbers and texts that identifies something unique, and tells us how to verify the authenticity of the matter.
Verifiable Credentials (VC)
Verifiable Credentials (VC) is a standard format for expressing credentials that can be issued, signed, shared, stored.
When a DID is used as an identifier of a document, that document can be called a Verifiable Credential.
There are 3 main types of identities (each an evolution from its predecessor):
- Centralised Identities: all service providers such as Gmail, Yahoo, that requires you to login to their system using your username and password.
- Federated identities: Json Web Token (JWT) and SAML Assertion
- Decentralised Identities: Verifiable Credentials (VCs).
DID methods can also be developed for Federated or Centralized identity management systems. For their part, all types of identifier systems can add support for DIDs, creating an interoperability bridge between the worlds of centralized, federated and decentralized identifiers.
The architecture of DIDs are laid out by W3C’s Recommendations. More information can be found here.
