- SAP Managed Tags:
Fifteen years after Bitcoin's white paper[1], there’s still so much noise, uncertainty, and no enterprise adoption. Blockchain, DLT, DeFi, NFT, SSI, and so many other concepts are lingering between being a mere buzzword or the future of the enterprise.
In this article, I would like to share our learnings by highlighting two major and mostly overlooked impediments hindering enterprise adoption of decentralized ecosystems. These impediments remind us why software solutions are relevant for enterprise challenges. I will also share a problem that can be addressed by a decentralized approach today and propose a solution. Ultimately, I want to invite interested individuals and parties to collaborate and realize it.
Since everything started with Bitcoin, let's begin with requirements that influenced Bitcoin's architecture. Bitcoin is a peer-to-peer online payment system with no intermediary. It's been used as a reference to trade other goods and services without borders. Being an online payment system made Bitcoin a global store of value[2] and influenced its security requirements.
"No intermediary" means no trusted coordinator, and trust comes from the reputation of an identity. Bitcoin has no assumptions about reputation of participants. Reputation is "quality seen or judged by people." In other words, we judge someone's future behaviour based on their past. Since we can't see and judge every single participant in a global peer-to-peer network, making decisions based on their past will be infeasible and a wrong expectation. Think of a global store of value managed based on reputation. It means its security is tied to the reputation of the operators. Reputation can change, but changing a global payment system because of operators’ reputation change will be burning an unsustainable global store of value.[3] A sustainable global payment solution allows international participation and should live forever.
Thus, Bitcoin's choice of proof-of-work[4] – a technical solution to verify that computation has been done correctly – rescues network security from relying on reputation. The computation would generate a block randomly every 10min. No matter how many valid blocks a participant has generated in the past, they must put in the same effort as others to develop a new one, again and again.
Not relying on reputation unlocks other important features. Disagreements can be solved without manual interventions by accepting the longest chain, as a rule, coded in the network. Block generation reward incentivizes contributions to the network's security without judging the contributor, which is the most inclusive form of expanding the Bitcoin community.
But Bitcoin is just a number assigned to a string compared to what humans are capable of. Our world is built on top of identity and reputation because it's impossible to code all human interactions – at least today :). That's also why our real world can't be fully automated.
Enterprises strive to scale. Complex (but intelligent and flexible) humans that can't be automated should be trusted to simplify processes before scaling starts. And reputation is a tool to build that trust.
People who don't have enough exposure to either decentralized or enterprise worlds tend to force tools or features from one world to another. Some think the global supply chain must be written on their blockchain! Some expect a decentralized network to provide instant finality and 1000s of transactions per second! Some believe they must know everyone in a peer-to-peer network before using it! Some even think bringing reputation from enterprise in a peer-to-peer network is the solution to global scalability of blockchain solutions!
As there is only one internet, there can't be 1000s of networks to onboard enterprises.
To lower the risk of buying into a soon obsolete network and to avoid the cost of adopting many, enterprises wait till the space is consolidated. Or they might bootstrap their network and expect their competitors to join! Or similar reasonably selfish behaviours which worsen the situation. This feeds a vicious cycle of increasing networks that makes the matter even more complicated and slows any adoption.
On the other hand, those enterprises expecting a decentralized network as a middle ground to collaborate with competitors are willing to participate in network operation (by running a full node) to ensure its neutrality. With many networks, guaranteeing the neutrality of all might require running 1000s of nodes from 1000s of networks making collaboration unreasonably costly. Furthermore, bridging those networks via a central or peer-to-peer integration will be infeasible and not scalable globally.
An enterprise expects to be in one network with all its n-tier international supply chain partners. Bootstrapping a new network per application, per group of companies, or even per country won't scale.
Enterprises need digital solutions to scale. Automation would be the very primitive expectation from software to improve efficiency and facilitate global scalability. Existing solutions, let it be an Excel file or a sophisticated ERP system, at the most address the challenges of a single business. However, today's supply chain is an intertwined global network with complex issues that can be tackled only by collaborating with all supply chain participants. This collaboration is prolonged and limited due to preferred communication channels, emails, and files instead of properly integrating backend systems. At best, one can reach the extent of a business network operated by a single vendor.
Imagine a world where your backend systems could discover, authenticate, and communicate with your business partners' backend systems and you, as the business owner, have full control over how much automation is desirable. Imagine global connectivity as extensive as the internet.
One root cause preventing such a dream is the absence of a universal digital identity for companies. An Identity portable across vendors and solutions while being fully controlled by its owner. Established and matured technologies cannot provide a global identity without creating a single point of failure. They also require a lengthy manual governance process for onboarding international competing solutions.
Self-Sovereign Identity[5] (SSI) introduces an opportunity to solve this issue. Companies can create their identifiers independent of 3rd parties (Decentralized Identifier – DID[6]); the same identifier can be reused across various vendors, applications, and use cases. Corresponding authentication and communication methods are published as a DIDDocument on an accessible Verifiable Data Registry (Registry).
Trust has been established by companies requesting credentials[7] from reputable entities (Issuers). Backend systems could leverage these credentials as machine-verifiable business cards that could be verified independently, restoring missing privacy of business relations from issuers.
Using verifiable credentials and public data from the registry, backend systems can discover and authenticate each other and initiate trusted communication, eliminating the manual exchange of emails and files.
Currently, the SSI concept has various implementations.[8] Each has been designed based on a different set of requirements. But how the Registry operates is the key design element that controls portability and sovereignty. Various disconnected Registries raise the issue of consolidating many networks. If ignored, we are left with 100s of SSI networks and 1000s of central identity providers to bridge. Eventually, companies will delegate this task to 3rd party providers, usually competitors, and be left with a new set of complex silos to bridge. A more complex and expensive identity solution with no added value is a recipe for failure.
On the other hand, future consolidation of SSI networks run by various consortia with various legal contracts in different jurisdictions will be a complicated and lengthy process, if not impossible, especially when they have business models tied to operating their network.
To highlight the issue, let’s elaborate on two known approaches for operating a Registry.
Regarding SSI architecture, Registry is the key to balancing sovereignty and portability. It coordinates participants (issuers, owners, and verifiers) on the latest changes in authentication and communication methods. A common global Registry could address cross-network communication issues, meaning identifiers are portable and accessible globally.
Both approaches mentioned above require established trust in identities behind operators of a Registry. Following the same trust assumption, ideally, a global multistakeholder identifier network operated by trusted known entities could solve this issue[12]. Of course, it needs global coordination and governance, which has not even started yet.
But what if we could remove this demanding requirement of known identities? Operating a global network for the Registry without knowing other node operators of our network! The solution must provide a degree of guarantee that resolving DIDDocuments is (eventually) consistent globally. It also must allow identity owners to update their DIDDocument (sovereignty) and verifiers to resolve it when needed (portability).
ION[13] is an example of a global Registry built on a decentralized ecosystem. It uses IPFS[14] as a distributed[15] storage to share transactions and the Bitcoin network to timestamp batches of transactions as a neutral coordinator. Everyone can join or leave anytime without disrupting the network operation, providing a minimum entry barrier leading to organic growth.
What about trust? Well, as defined by SSI, issuers are trust anchors and are separated from Registry. The same issuers from existing SSI networks can hold their issuer role and use ION as a universal identifier instead of a local identifier.
Small and medium enterprises could run a read-only ION node if desired and rely on other nodes for write operations or delegate these tasks to existing trusted 3rd parties. Another difference would be that in a global Registry, migrating identifiers will be meaningless since the network is co-owned by everyone, and thus no fear of vendor lock-in. The result will be a single network that grows organically, and thus with new members, companies don’t need to connect their resolvers to new nodes.
That's how a global SSI network for company identity can be realized without sacrificing sovereignty and portability. With a common identifier, companies' backend systems can use their universal identifiers and corresponding verifiable credentials across all vendors and use cases, eliminating the hassle of mapping local identifiers and risks of a single point of failure and vendor lock-in from bridges. Connected backend systems will be more efficient than emails and files, providing more room for automation and scale. That’s why enterprises need a decentralized ecosystem to scale their supply chain collaboration globally.
If you enjoyed this article and want to learn more or collaborate, please don't hesitate to reach out. A decentralized future is coming, and it won't wait for us. We either prepare or expect a disruption.
[1] https://bitcoinwhitepaper.co/
[2] https://www.nasdaq.com/articles/bitcoin-is-a-store-of-values
[3] Imagine the impact of collapsing USD value to zero, considering USD, the closest example to a global payment system, although maybe not a good long-term store of value.
[4] https://en.wikipedia.org/wiki/Proof_of_work
[5] https://medium.com/decentralized-identity/where-to-begin-b2a55b898b3
[6] https://www.w3.org/TR/did-core/
[7] https://www.w3.org/TR/vc-data-model/
[8] SSI is a concept like connecting the world. There are several proposals for its specification and, consequently many deployments. In the same way that the highest value realization is happening with the internet, not local networks, a single SSI network deployment will have the highest value and become de facto for global identity.
[9] https://w3c-ccg.github.io/did-method-web/
[10] Latest three examples
[11] Resolver’s role is to resolve an identifier (DID) to the latest state of corresponding DIDDocument which is essential for authentication and communication.
[12] Similar to https://www.icann.org/
[13] https://identity.foundation/ion
[14] https://ipfs.tech
[15] Distributed is not the same as decentralized in a sense that in a decentralized network, every node has a full copy of all data where in a distributed network, data is partially distributed among few nodes.
In this article, I would like to share our learnings by highlighting two major and mostly overlooked impediments hindering enterprise adoption of decentralized ecosystems. These impediments remind us why software solutions are relevant for enterprise challenges. I will also share a problem that can be addressed by a decentralized approach today and propose a solution. Ultimately, I want to invite interested individuals and parties to collaborate and realize it.
Impediments
Importance of Requirements and Features Compatibility
Since everything started with Bitcoin, let's begin with requirements that influenced Bitcoin's architecture. Bitcoin is a peer-to-peer online payment system with no intermediary. It's been used as a reference to trade other goods and services without borders. Being an online payment system made Bitcoin a global store of value[2] and influenced its security requirements.
"No intermediary" means no trusted coordinator, and trust comes from the reputation of an identity. Bitcoin has no assumptions about reputation of participants. Reputation is "quality seen or judged by people." In other words, we judge someone's future behaviour based on their past. Since we can't see and judge every single participant in a global peer-to-peer network, making decisions based on their past will be infeasible and a wrong expectation. Think of a global store of value managed based on reputation. It means its security is tied to the reputation of the operators. Reputation can change, but changing a global payment system because of operators’ reputation change will be burning an unsustainable global store of value.[3] A sustainable global payment solution allows international participation and should live forever.
Thus, Bitcoin's choice of proof-of-work[4] – a technical solution to verify that computation has been done correctly – rescues network security from relying on reputation. The computation would generate a block randomly every 10min. No matter how many valid blocks a participant has generated in the past, they must put in the same effort as others to develop a new one, again and again.
Not relying on reputation unlocks other important features. Disagreements can be solved without manual interventions by accepting the longest chain, as a rule, coded in the network. Block generation reward incentivizes contributions to the network's security without judging the contributor, which is the most inclusive form of expanding the Bitcoin community.
But Bitcoin is just a number assigned to a string compared to what humans are capable of. Our world is built on top of identity and reputation because it's impossible to code all human interactions – at least today :). That's also why our real world can't be fully automated.
Enterprises strive to scale. Complex (but intelligent and flexible) humans that can't be automated should be trusted to simplify processes before scaling starts. And reputation is a tool to build that trust.
People who don't have enough exposure to either decentralized or enterprise worlds tend to force tools or features from one world to another. Some think the global supply chain must be written on their blockchain! Some expect a decentralized network to provide instant finality and 1000s of transactions per second! Some believe they must know everyone in a peer-to-peer network before using it! Some even think bringing reputation from enterprise in a peer-to-peer network is the solution to global scalability of blockchain solutions!
Too Many Networks
As there is only one internet, there can't be 1000s of networks to onboard enterprises.
To lower the risk of buying into a soon obsolete network and to avoid the cost of adopting many, enterprises wait till the space is consolidated. Or they might bootstrap their network and expect their competitors to join! Or similar reasonably selfish behaviours which worsen the situation. This feeds a vicious cycle of increasing networks that makes the matter even more complicated and slows any adoption.
On the other hand, those enterprises expecting a decentralized network as a middle ground to collaborate with competitors are willing to participate in network operation (by running a full node) to ensure its neutrality. With many networks, guaranteeing the neutrality of all might require running 1000s of nodes from 1000s of networks making collaboration unreasonably costly. Furthermore, bridging those networks via a central or peer-to-peer integration will be infeasible and not scalable globally.
An enterprise expects to be in one network with all its n-tier international supply chain partners. Bootstrapping a new network per application, per group of companies, or even per country won't scale.
Relevant Enterprise Challenges
Enterprises need digital solutions to scale. Automation would be the very primitive expectation from software to improve efficiency and facilitate global scalability. Existing solutions, let it be an Excel file or a sophisticated ERP system, at the most address the challenges of a single business. However, today's supply chain is an intertwined global network with complex issues that can be tackled only by collaborating with all supply chain participants. This collaboration is prolonged and limited due to preferred communication channels, emails, and files instead of properly integrating backend systems. At best, one can reach the extent of a business network operated by a single vendor.
Imagine a world where your backend systems could discover, authenticate, and communicate with your business partners' backend systems and you, as the business owner, have full control over how much automation is desirable. Imagine global connectivity as extensive as the internet.
Root Cause and Potential Solution
One root cause preventing such a dream is the absence of a universal digital identity for companies. An Identity portable across vendors and solutions while being fully controlled by its owner. Established and matured technologies cannot provide a global identity without creating a single point of failure. They also require a lengthy manual governance process for onboarding international competing solutions.
Self-Sovereign Identity[5] (SSI) introduces an opportunity to solve this issue. Companies can create their identifiers independent of 3rd parties (Decentralized Identifier – DID[6]); the same identifier can be reused across various vendors, applications, and use cases. Corresponding authentication and communication methods are published as a DIDDocument on an accessible Verifiable Data Registry (Registry).
Trust has been established by companies requesting credentials[7] from reputable entities (Issuers). Backend systems could leverage these credentials as machine-verifiable business cards that could be verified independently, restoring missing privacy of business relations from issuers.
Using verifiable credentials and public data from the registry, backend systems can discover and authenticate each other and initiate trusted communication, eliminating the manual exchange of emails and files.
Abstract SSI Architecture
Many SSI Solutions to Pick
Currently, the SSI concept has various implementations.[8] Each has been designed based on a different set of requirements. But how the Registry operates is the key design element that controls portability and sovereignty. Various disconnected Registries raise the issue of consolidating many networks. If ignored, we are left with 100s of SSI networks and 1000s of central identity providers to bridge. Eventually, companies will delegate this task to 3rd party providers, usually competitors, and be left with a new set of complex silos to bridge. A more complex and expensive identity solution with no added value is a recipe for failure.
On the other hand, future consolidation of SSI networks run by various consortia with various legal contracts in different jurisdictions will be a complicated and lengthy process, if not impossible, especially when they have business models tied to operating their network.
To highlight the issue, let’s elaborate on two known approaches for operating a Registry.
- Central Registry: An example is “did: web”[9] where identity owners publish their DIDDocument under their web domain inheriting established trust in web and resolvable via DNS. It provides maximum control to the identity owner. Assuming all security and privacy concerns are addressed, each company must maintain a trusted list of domains from all their n-tier supply chain participants to connect the global supply chain. Remember, there are enterprises with 10s of 1000s of suppliers and customers.
- If the domain intentionally or unintentionally presents two conflicting versions of DIDDocuments, there is no automated way to resolve the issue, leading to lengthy disputes to be addressed manually and creating more friction in the supply chain.
- If today’s IdPs expose such a public API, do we need SSI? Isn’t this similar to point-to-point integration, which is known to be globally not scalable?
- Permissioned Network: where a few vetted and trusted entities are selected to be the node operators of a permissioned blockchain network maintaining the Registry. Even if they overcome the known issues of high costs and low adoption of permissioned networks[10], they will still create new islands of trust. A new permissioned network per industry, application, country, brand, and in general born of any incentive to create an exclusive club. Participants of the same supply chain but different SSI networks have three options to connect:
- Run a full node from each other’s networks that is not efficient.
- Rely on a trusted 3rd party to bridge all networks (a.k.a. universal resolver). In this case, the trusted party acts as a central IdP and defies the need for any SSI solution.
- Self-host a resolver[11] connected to relevant networks. Permissioned networks provide a full list of trusted nodes with which a resolver can randomly interact to ensure network resiliency and privacy. Thus, connecting a resolver to a new network requires maintaining a trusted list of addresses of nodes operating that network! At the same time, it’s expected to trust the response from those nodes to be the latest state of a resolved DIDDocument. Here it might be a bit confusing, concluding with “we need to trust the node operators of the other network with resolving their DIDDocument” while assuming that “we don’t trust them to resolve ours, that’s why we establish our permissioned network with our trusted operators”! Assuming all security concerns are addressed for maintaining and publishing a list of trusted nodes when participants of the same supply chain need to connect, the picture will look like the one below. Every company must manage a growing list of trusted nodes connected to its resolver. If we trust the node operators’ response, isn’t “did:web” more efficient to manage? For my trust circle, I trust their domain “did:web”, and for other networks, anyway, I don’t have any other option. Does the complexity of SSI implementation with permissioned networks outweigh the shortcomings of established solutions? What about migrating from one trust circle (Registry) to another? Shouldn’t I request all credentials (VC) again?
Companies from different SSI networks must connect their resolvers to their business partners’ network nodes. The above picture shows only one company setup. The same connections must be established for the other two partners as well. The setup grows in complexity as the number of SSI networks increases.
Solution Proposal
Regarding SSI architecture, Registry is the key to balancing sovereignty and portability. It coordinates participants (issuers, owners, and verifiers) on the latest changes in authentication and communication methods. A common global Registry could address cross-network communication issues, meaning identifiers are portable and accessible globally.
Both approaches mentioned above require established trust in identities behind operators of a Registry. Following the same trust assumption, ideally, a global multistakeholder identifier network operated by trusted known entities could solve this issue[12]. Of course, it needs global coordination and governance, which has not even started yet.
But what if we could remove this demanding requirement of known identities? Operating a global network for the Registry without knowing other node operators of our network! The solution must provide a degree of guarantee that resolving DIDDocuments is (eventually) consistent globally. It also must allow identity owners to update their DIDDocument (sovereignty) and verifiers to resolve it when needed (portability).
ION[13] is an example of a global Registry built on a decentralized ecosystem. It uses IPFS[14] as a distributed[15] storage to share transactions and the Bitcoin network to timestamp batches of transactions as a neutral coordinator. Everyone can join or leave anytime without disrupting the network operation, providing a minimum entry barrier leading to organic growth.
What about trust? Well, as defined by SSI, issuers are trust anchors and are separated from Registry. The same issuers from existing SSI networks can hold their issuer role and use ION as a universal identifier instead of a local identifier.
Small and medium enterprises could run a read-only ION node if desired and rely on other nodes for write operations or delegate these tasks to existing trusted 3rd parties. Another difference would be that in a global Registry, migrating identifiers will be meaningless since the network is co-owned by everyone, and thus no fear of vendor lock-in. The result will be a single network that grows organically, and thus with new members, companies don’t need to connect their resolvers to new nodes.
Node operators sharing the same identifier Registry. Companies from different trust circles don’t need to connect their resolvers to other nodes outside of their trust circle. New members can join as they come and grow the network organically.
That's how a global SSI network for company identity can be realized without sacrificing sovereignty and portability. With a common identifier, companies' backend systems can use their universal identifiers and corresponding verifiable credentials across all vendors and use cases, eliminating the hassle of mapping local identifiers and risks of a single point of failure and vendor lock-in from bridges. Connected backend systems will be more efficient than emails and files, providing more room for automation and scale. That’s why enterprises need a decentralized ecosystem to scale their supply chain collaboration globally.
If you enjoyed this article and want to learn more or collaborate, please don't hesitate to reach out. A decentralized future is coming, and it won't wait for us. We either prepare or expect a disruption.
[1] https://bitcoinwhitepaper.co/
[2] https://www.nasdaq.com/articles/bitcoin-is-a-store-of-values
[3] Imagine the impact of collapsing USD value to zero, considering USD, the closest example to a global payment system, although maybe not a good long-term store of value.
[4] https://en.wikipedia.org/wiki/Proof_of_work
[5] https://medium.com/decentralized-identity/where-to-begin-b2a55b898b3
[6] https://www.w3.org/TR/did-core/
[7] https://www.w3.org/TR/vc-data-model/
[8] SSI is a concept like connecting the world. There are several proposals for its specification and, consequently many deployments. In the same way that the highest value realization is happening with the internet, not local networks, a single SSI network deployment will have the highest value and become de facto for global identity.
[9] https://w3c-ccg.github.io/did-method-web/
[10] Latest three examples
[11] Resolver’s role is to resolve an identifier (DID) to the latest state of corresponding DIDDocument which is essential for authentication and communication.
[12] Similar to https://www.icann.org/
[13] https://identity.foundation/ion
[14] https://ipfs.tech
[15] Distributed is not the same as decentralized in a sense that in a decentralized network, every node has a full copy of all data where in a distributed network, data is partially distributed among few nodes.
3 Comments
