Decentralized identity and why you should care - part 2
Credit goes to Ankur Patel @ MSFT
What is this?
In part 1 of this series, we took a 30,000 foot look at ‘decentralized identity’ and why it’s super cool. We looked at problems with the current identity landscape, and how they can be solved by placing the ownership of an identity with the actual person oppose to organization or service.
In this post, we will look at technical details and how it works.
Some identity specific jargon
There are a few phrases we need to get out of the way first:
- Public key cryptography
- A cryptographic process that uses a key-pair (public/private keys) to facilitate secure communications, strong authentication, and message integrity
- Blockchain
- A digital ledger where transactions (generally public, also known as blocks) are recorded in a cryptographically secure manner and cannot be reversed, modified or changed (easily).
- Wallet
- A digital safe which can store information you own, where ownership is proved by way of a private key only you know or has. This wallet proves ownership of transactions on a given blockchain.
- Decentralized Identities (DIDs)
- The digital identity of a person who is complete control of their identity; where they can securely and privately store data. Contains an ID and it’s public key. Stored on a blockchain.
- Self-soverign identity
- A lifetime portable identity for any person, organisation, or thing that does not depend on any centralised authority and can never be taken away - Drummond Reed, Evernym
- Verifiable credential
- Is a tamper-evident credential that has authorship that can be cryptographically verified.
- Universal resolver (at time of writing)
- The ability to resolve and translate DIDs and public-keys on the blockchain, like DNS for hostname/IP.
The example
Let’s give the example of a doctor. A doctor will go and work at a hospital. She will interview at the hospital, the hospital will verify some form of doctor credential, and allow her to begin work. How can the hospital ensure the doctor is actually qualified to operate on patients, likewise how can the doctor securely prove she is who she says she is and has these credentials?
The doctor needs a credential from a hospital to start working. When she rocks up to the hospital, she provides her newly-issued hospital credential to begin working.
Parties involved
There are several parties involved, using the above ‘jargon’ to enable a decentralized identity platform:
- The doctor
- The administrator at the hospital - who approves doctors
- The medical board of Australia (MBoA) - who provisions doctor credentials (credential is stored in wallet for this example and are already cryptographically signed)
- Azure-AD (AAD) - used as interface to blockchain and perform validation, also to store shadow identites of hospital staff and provide bindings for DID and accounts which have been validated
The process - signup
First thing first, doctor wants to start work. How does this process look?
1. Doctor visits the hospital, proving her identity by way of a physical passport or other such verifications the hospital accepts.
2. Sysadmin/staff create her account, say in active-directory.
3. Doctor provides her wallet and crypto. signed DID to the hospital system
4. Hospital system asks for validation of her DID (stored in her wallet already as per above).
5. Hospital takes provided MBoA credential and validates it with MBoA. This is by way of the provided signed DID and signed MBoA credential.
6. Hospital creates a signed JSON web token (JWT) with information about the doctor, including her newly created account, her DID, the hospital's DID and is signed.
7. JWT is send to AAD
8. AAD then get's hospital's DID from blockchain. JWT is now verified.
9. AAD verifies the doctors account is valid, sets up the AAD/DID binding on the account. Dcotor's public key is stored against account.
The process - sign-in
Doctor has now proved who she says she is and that she can practice medicine. When she rocks up to the office to begin her day, how does the sign-in process look?
1. Doctor chooses to sign-in with wallet/DID
2. OIDC redirected to IdP (AAD)
3. Doctor redirected to page with generated QR code
4. Doctor scans QR code with wallet
5. Doctor generates self-signed JWT that contains DID
6. DID POSTed to AAD
7. DID verified by public key stored from sign-up process
8. Validates the AAD account is valid
9. New ID token is generated by AAD, provided to hospital for sign-in
10. Doctor is logged in
What just happenned?
The above is a gross oversimplification, I left out ~2-3 services for simplicity sake, but in essence the doctor was able to be securely verified as a medical professional without giving up her identity or exposing personal information. What was still required (currently) is something like a passport or drivers license.
There’s also components required on-prem at the hospital (or within their system), and in this example the medical board needs to have information on the public blockchain to take part in the process.
There’s also some back-end components required for the hospital in Azure - Azure AD, keyvault, graph API capabilities, the universal resolver to translate information to and from the blockchain and a few other things.
Another thing is that you can’t get around the physical security aspect; if you’re asleep and someone uses your finger to unlock your phone, this system cannot get around that.
Moving forwards
The above process will be simplified somewhat as a service - you may find lots of the complexity is managed as a service, likewise the ability to join multiple different ledgers (such as blockchain or etherium-based systems) is desired.
Overall, this is an exciting technology process which breaks existing barriers for citizen identity privacy and control. This enables organizations to issue and validate credentials in a secure manner, where no central authority controls any identity.