Factom vision — the building blocks, part 1
As I mentioned in my previous story about vision and which has been way too long ago, the Factom Protocol has seen a lot of development since it’s decentralization little over a year ago. I will talk about the challenges we have faced and are still facing in future articles. I would like to take this moment to talk about my personal vision for the Factom Protocol and where I believe the protocol should be headed.
Factom has long been mostly about Proofs alone. You have this fingerprint called a hash of an object or file, or have this series of hashes to do proofs. Proof of Existence, Proof of Process etc. In itself that is really important for independently verifiable proofs and audits, but not necessarily the most sexy use case in blockchain. Since the inception of the grant pool in Factom to pay for development, marketing and governance related work we have seen many projects and products being added to the ecosystem. It is now time to share part of Sphereon’s , Triall’s and my personal vision for the protocol to kick of a wider discussion about the future of Factom. This is part of multiple stories as I would like to take the time for the less technical inclined people to get the full vision. Please note that the vision will be mentioned in part during every single story, but the last story will be about how it all should fit together according to me. These stories will be about identities, verifiable credentials, zero knowledge proofs, tokenization, smart contracts, stable coins, IoT and general data proofs and how that all fits together in one single platform where the user can model their own data as well.
Data blockchain — refresher
Factom is a pure data blockchain, allowing people to create their own data structures on top in chains you can create yourself. The concept is really powerful much like your own file cabinet or Inbox, where you are in control how you archive your e-mails. You can put all your e-mail in one Inbox or you can create a complete nested folder structure with e-mail distributed amongst them. It is up to the owner to decide what works best. This characteristic is a really important one and more on that later!
Identities on Factom (DIDs)
Factom has had native identities from the start, but recently Decentralized Identifiers (DIDs) have been added. DIDs are current a W3C community specification, but with backing by major players like Microsoft we believe DIDs will form the basis for identity management in the future. DIDs are also called self sovereign identities and they are the key to enabling all kinds of solutions. From signing data, to voting, to web(app) authentication, to attestations and claims. A DID is attached to you as a person, to your device(s) or could even be attached to your children or pets. In that case you are in control of their identity as a pet obviously cannot do that itself.
This identity is cross ledger and can best be compared with a URL you type in your browser to visit a website. The DID points to a document on a blockchain that holds information about an identity. Of course that identity is a living thing. It can be updated or revoked over time. Also you would poses several different identities over time and at the same time. There is software available that allows IT vendors to integrate DIDs across several blockchains in a universal manner.
The Factom Protocol is a really nice blockchain because of it’s fixed low price data entry, meaning DIDs also have a fixed low price on Factom. DIDs are primed to become the standard identity solution on top of the Factom protocol, mostly replacing the native identities and certainly replacing the so called node/server identities that are in place today on the Factom blockchain. Every product/project on top of Factom should standardize on DIDs in my opinion. Luckily we have Factom Interoperability Specifications now (more on that in another article), which provide specifications for vendors to make sure their application will be interoperable with other products performing similar functions.
DIDs and Privacy by Design
(shamelessly copied from the W3C DID primer)
Privacy is an essential component of any identity management solution. A DID architecture can incorporate Privacy by Design at the very lowest levels of infrastructure and thus become a powerful, new, privacy-preserving technology if deployed using best practices such as:
- Pairwise-pseudonymous DIDs. While DIDs can be used as well-known public identifiers, they can also be used as private identifiers issued on a per-relationship basis. So rather than a person having a single DID, like a cell phone number or national ID number, she can have thousands of pairwise-unique DIDs that cannot be correlated without her consent, yet can still be managed as easily as an address book.
- Off-chain private data. Storing any type of PII on Factom or any public blockchain, even encrypted or hashed, is dangerous for two reasons: 1) the encrypted or hashed data is a global correlation point when the data is shared with multiple parties, and 2) if the encryption is eventually broken (e.g., quantum computing), the data will be forever accessible on an immutable public ledger. So the best practice is to store all private data off-chain and exchange it only over encrypted, private, peer-to-peer connections.
- Selective disclosure. The decentralized PKI (DPKI) that DIDs make possible opens the door to individuals gaining greater control over their personal data in two ways. First, it enables it to be shared using encrypted digital credentials. Second, these credentials can use zero-knowledge proof cryptography for data minimization, e.g., you can disclose that you are over a certain age without disclosing your exact birthdate.
Trust
How can 2 parties trust each other though when the identities have not been build using traditional federated solutions like SSL certificate authorities? These identities have been completely build from scratch by the users themselves remember.
- Use Challenge/response messages for real-time verification of keys. Only the owner of the private key can interact and make sure the challenge completes successfully.
- Exchange of credentials signed by other trusted parties, so called “verifiable credentials”, whose public keys can also be verified against a ledger of choice by virtue of DIDs. More in this subject further down ;)
Decentralized Key Management Systems (DKMS)
Identities alone however are not enough. You need easy applications and solutions to create and manage your identities, and to manage identities of others. Think of a single person, pet or device. These identities need to interact with other identities. Either pairwise, in groups, within business units or organizations. Remember you will not have one DID, you will probably have hundreds and in most cases one per relationship. A relationship can be again a person, device, pet, organization or group of people. See it like your own private encrypted channel to interact with each other. All that identity management requires an easy to use and comprehensive system.
You need to be able to easily create, replace and retire keys without having to know all the fine details. Much like you use a wallet for cryptocurrencies without knowing how that actually works (for most people ;) ). TCP/IP connects all the computers nowadays, but only a really small percentage of people know how that works. You don’t need to know/worry about it.
As system that ideally allows you to model real world relationships. Meaning you want this to be available both to individuals as well as companies, organizations and even clubs and associations, or in Factom governance for instance for standing parties like guides, Authority Node Operators, users of the protocol and Factoid token holders.
DID Authentication
What is wrong with our current password based authentication? To quote https://webauthn.guide/
Passwords have an ever-growing list of problems associated with them, both for users and developers. Users have to worry about passwords being stolen by phishing tools, or their passwords being leaked online if websites they have accounts with are compromised. They have to worry about creating and remembering passwords without dedicated password management tools. Developers have to worry about all the complications of passing passwords through systems and safely storing them in databases.
WebAuthn to the rescue! WebAuthn is a really recent specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft and others. It is supported by Windows 10, Chrome, Firefox, Edge and upcoming support on Safari. With mobile implementations for Android and soon IoS.
It works using public and private keys instead of passwords to quote the above site again:
It allows servers to integrate with the strong authenticators now built into devices, like Windows Hello or Apple’s Touch ID. Instead of a password, a private-public keypair (known as a credential) is created for a website. The private key is stored securely on the user’s device; a public key and randomly generated credential ID is sent to the server for storage. The server can then use that public key to prove the user’s identity.
The public key is not secret, because it is effectively useless without the corresponding private key. The fact that the server receives no secret has far-reaching implications for the security of users and organizations. Databases are no longer as attractive to hackers, because the public keys aren’t useful to them.
But that is not DIDs right?
Nope you are absolutely correct, but DIDs are build using the same principles. Public and private key pairs. A DID has specific mechanisms for authentication purposes, called DID-auth
To quote https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md
We define DID Auth as a ceremony where an identity owner, with the help of various components such as web browsers, mobile devices, and other agents, proves to a relying party that they are in control of a DID. This means demonstrating control of the DID using the mechanism specified in the DID Document’s “authentication” object. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to establish mutually authenticated communication channels and to authenticate to web sites and applications.
Although the scopes of both differ, I do hope people see the resemblance and the fact that DID authentication for instance allows Public and Private key pairs to be used, it makes WebAuthn and DID-auth a nice pair.
Using DIDs for authentication means you need to have proper solutions to provide the authentication. Currently Off-Blocks a digital identity and signature solution on top of Factom and Sphereon a BaaS and blockchain integration specialist are looking to add DID auth and WebAuthn support into off-blocks. Authenticator support has been on the roadmap of Off-Blocks for quite some time, but even with the app not out yet we are seeing demand for this use case already.
What’s next
We only scratched the surface. The next story will be about Verifiable Credentials, Zero knowledge proofs, Identity hubs, followed by pieces about tokenization, smart contracts and iOT, followed by “the vision”.
Let me know what you think.
