The Dawn of Organizational Identity, Part 2: Credentials

Co-authored by Stephan Wolf, CEO of GLEIF. Thanks to the dozens of smart people who contributed their time and insights.

Part 1 described the first component of Organizational Identity (OI): identifiers. Part 2 describes the second component of OI — organizational credentials — the things that bring OI its most exciting and transformative capability: verifiable authority.

Organizational Credentials

Organizational Credentials (OCs) enable representatives of an organization to prove their authority to represent the organization outside its boundaries to anyone, anywhere. Critically, OCs enable this without using identity providers (IDPs), blockchains, or shared platforms. Instead, OCs are fully decentralized, utilizing free and open key management protocols at the edges of interactions instead of depending on a centralized intermediary or common master database, ledger, or registry in the middle. More on that later.

Mechanically, OCs cryptographically bind a natural person or thing to their organizational attributes. OCs specifically pronounce and make proveable the authority, roles, rights, and responsibilities of organizational representatives. OCs also prove the identity of the representative and organization being represented, and cryptographically bind them together so that all three elements — the organization, the identity of the representative, and the authority attributes of the representative — are instantly verifiable anywhere, online or off.

Unlimited Use Cases

The use cases for OCs are endless, and profound. OCs make possible all the dreamy things mentioned at the beginning of Part 1. Because they’re important, here they are again with a few changes:

B2B Examples

• Authorized representatives will digitally sign documents, contracts, purchase orders, and attestations; recipients of those signatures will instantly verify signers’ authority (and some digital documents will prevent signing without the expected authority);
• The origin, chain of custody, and authority of a legitimate document, agreement, filing, or piece of data will be instantly verifiable as authentic and un-tampered with;
• Phone calls, texts, email, and other digital communications originating from authorized representatives (or devices) of an organization — or any delegate of that organization — will be instantly verifiable, as will the authority of the originating representative;
• The authority of every approval, signature, or other digital action in a supply chain will be instantly verifiable by downstream actors, and auditable in real-time;
• Login by employees, contractors, customers and constituents will become passwordless and based on authority and entitlement, not passwords or devices;
• Impersonation and ID theft of authorized representatives will become more difficult for fraudsters;
• Security breaches will become shorter, less frequent and less impactful, as organizations adopt more robust OI and key management strategies;
• And on and on.

B2C and C2B Examples

• AI/bots will prove legitimacy by non-repudiably digitally signing all content they produce;
• Organizations will instantly recognize their customers and constituents when they call in, log in, or walk in, enabling superior customer experiences without sacrificing security or privacy;
• People will verify that a business or government representative contacting them has the authority they claim;
• Access controls — both physical and digital — will become more granular and secure;
• A car (and its driver) will wirelessly verify the authority of approaching law enforcement or emergency vehicles, and be granted preferential access, terms, or parking benefits for being local;
• A contracted delivery driver can use a one-time-use OC to open a gate;
• And on and on.

Protocols, Not Platforms = Fully Decentralized = No Boundaries

As mentioned above, OCs are verifiable anywhere — even outside the physical or digital boundaries where the organization exists, such as a network, state, country, or even group of countries — without using IDPs or other ‘trusted’ intermediaries, blockchains, or shared platforms.

Platform-based models require that verifiers ‘phone home’ to some trusted platform to perform verifications, similar to how Facebook users meet on the Facebook platform, LinkedIn users on LinkedIn, Twitter, Tiktok, and so on. If there’s an anointed/accredited provider or group of providers at the center of an identity ecosystem through which all interactions must pass, it’s a centralized platform limited in its usefulness to those who directly trust the particular provider(s) and subject to continuous digital surveillance.

By using open, standard, decentralizing protocols instead of platforms, OCs allow each side of an interaction to use any service provider they choose or build their own tooling, rather than having a platform in the middle that both sides of an interaction must use and trust. Take the example of email: when email was first invented, both senders and receivers needed to use the same platform to exchange messages — AOL, Compuserve, Prodigy, etc. After the introduction of the decentralizing SMTP protocol, however, email senders and receivers could each hire a separate service provider or host their own server, and still exchange email messages with anyone. Other examples of decentralizing protocols include TCP/IP, HTTP, etc.

Since the majority of OC users will likely buy tools from service providers instead of building their own, as with email, it is a big advantage that OCs allow counterparties to independently hire and fire their own service providers without losing the ability to successfully interact, no matter where in the world each party may be.

This separation not only enables ubiquitous verifiability, it solves a gaping privacy problem inherent with platform-based identity systems: the dreaded ‘phone home’ mentioned above that enables surveillance everywhere the digital identities are used, even if proponents say “we’re not implementing it that way” (yet). This separation also decentralizes valuable identity data at the edges rather than aggregating it into a tempting treasure trove in the middle, held by one or an anointed few central identity providers.

A few quick thoughts about blockchain… Blockchain, from a data standpoint, results from implementing a centralizing protocol, as it inescapably results in a single, master set of data that all counterparties must agree to (unlike TCP/IP, HTTP, etc.). While a blockchain’s data is physically replicated across many physical locations, the only semi-decentralized aspect of blockchain is its governance, but only when that governance is permissionless, and even then it is questionable.¹ Every aspect of permissioned blockchains is centralized, putting all data into a single logical ledger and governance into the hands of a chosen few. The point here is, blockchains in all their flavors are platforms, not protocols, and always result in data centralization, the opposite of what’s needed for globally verifiable OCs.

(Learn more about the centralizing aspects of platforms and decentralizing aspects of protocols in the seminal essay “Protocols, Not Platforms”, by Mike Masnick.)

OCs are Verifiable Credentials: Shipping Containers for Data

OCs can do everything that VCs (verifiable credentials) can do because OCs are VCs — though OCs are not reliant on blockchains or web security, as most VCs are (more on that below). VCs and OCs are like shipping containers for data: put any data inside a digital container, seal it up (by digitally signing it), send it anywhere, and a recipient anywhere can open it and instantly verify who created it and that it hasn’t been tampered with, revoked, or expired since it was issued.

To be doubly clear: an OC or VC does not prove its data payload to be true or correct, OCs and VCs prove the payload’s provenance (who originated it, who else endorsed it) and integrity (hasn’t been tampered with, expired, or revoked).

Because VCs are digital they can be presented and verified over and over again, and their security can be made to be quite high, depending on how they’re implemented. Bottom line: VCs make verifiable data portable, and OCs use that portability to prove authority delegated from an organization to a representative, whether a person or a thing.

(Read more about the foundational breakthrough of VCs in a three-part series Timothy wrote here.)

OCs Use Second-Generation Verifiable Credentials

First-generation VCs, like the current VC JSON-LD standard at W3C or the emerging JWT standard at IETF, were developed with utility for individuals in mind, for proving relatively less complex things like identity, age, and academic credentials. They were and are a major breakthrough in digital identity, they’re what make ‘self-sovereign identity’ actually self-sovereign and ‘decentralized identity’ actually decentralized, by giving individuals a high degree of autonomy.

Second-generation VCs were developed with organizational use cases in mind, with all the capabilities of first-generation credentials plus sophisticated new capabilities that individuals don’t often need but organizations often do, such as key pre-rotation and recovery, delegability, multi-signature (“multi-sig”), contractually protected disclosure, freedom from blockchain/‘ledger lock’, and more.

These new organizational capabilities are made possible by a form of VCs called “Authentic Chained Data Containers” (ACDCs), with signing and verification using a free, open key management protocol that replaces the need for blockchain or vulnerable web-based security: Key Event Receipt Infrastructure (KERI). These two decentralizing protocols together — ACDCs and KERI — deliver significant advances for VCs, the kind that organizations require and that justify the ‘second-generation’ moniker.

Here are seven highlights:

1. Extraordinary advances in security:

• Recovery from key compromise (suspected or actual) without reissuance of previously signed items*
• Key pre-rotation without re-issuance of previously signed items*
• No reliance on web security
• Privacy-respecting verifiable revocation
• Non-repudiable signing with logging
• Post-quantum proof*
• Natively supports weighted ‘m-of-n’ multi-sig schemes with fractionally weighted thresholds (e.g., 2-of-3’, or 1-of-3 when the 1 has sufficient ‘weight’, etc.)

2. No reliance on blockchain (and its limitations: “ledger-lock”/centralization, scalability, cost, complexity, interoperability, performance, privacy, security, etc.)

3. Use of existing cloud infrastructure and APIs

4. Multi-level issuance with chaining and delegation (anyone having authority can delegate and extend a chain of authority, rather than all delegates returning to the ‘mother ship’ for single-level, single-signer issuance)

5. Graduated disclosure (granular, legally enforceable privacy and disclosure capabilities):

• Selective disclosure*
• Contractually protected disclosure (parties verifiably consent to terms of disclosure prior to disclosure)
• Contingent disclosure (i.e., escrowed)

6. Interoperable with anything using the same underlying protocols (without sharing blockchains, vendors, registries, databases, etc.)

7. Simpler; technically lighter-weight (not verbose, compared to first-gen VCs)

*Individuals need these, too.

Security First, Always

With second-generation VCs, security comes first, always, no exceptions. The security advances with second-generation VCs are stunning when you consider that key recovery and rotation are still the Achilles Heel not only of first generation VCs, but also of blockchain and existing web infrastructure generally. Second-generation VCs using KERI don’t just fix security flaws for VCs (especially web-based VCs), they’re a significant advance in digital security, period.

Come on In, the Water’s Warm

There are no significant technical reasons we are aware of not to advance to second-generation VCs — no notable trade-offs other than familiarity and switching costs from legacy systems. In fact, the complexity of blockchain-based first-generation VCs may be at least an order of magnitude greater than the more elegant, advanced, and blockchain-less second-generation VCs.

That said, some will reasonably argue that a second-generation of VCs that doesn’t directly and fully interoperate with first-generation VCs — which is true — is a step backward rather than forward. However, we feel that achieving interoperability of VCs that are insecure, reliant on blockchain or web infrastructure, and not stress tested in production at scale is a hollow victory, and premature; it is not meaningful interoperability. Security — in the form of proper key management — must come first; it cannot be bolted onto the current VC model just like it cannot be bolted onto the internet after the fact; there is no way around this.

However, the good news is, with second-generation VCs we can have our cake and eat it, too: we can have all the robust security capabilities described above, plus advances in privacy simply not possible with first-generation VCs, and gain real, global, fully decentralized interoperability that only standardized non-platform-based protocols can deliver. Even then, serious work on interoperability should be undertaken only after some use cases have made it into production and demonstrated that all these things work well, at scale. Otherwise that would be premature interoperability, too.

The Unprecedented Power of OCs Using Second-Generation VCs

Some of the dreamy use cases for OCs listed above are already possible, you say… but:

• Unlike most current identity technologies, OCs require no surveillance-enabling, privacy-killing ‘phone home’ to an intermediary for verification, do not rely on DNS/web security, and do not use shared ledgers/blockchains; OCs sacrifice neither security nor privacy.
• OCs can convey the full provenance and details of authority — unlimited levels — in-band with verification, proving not only the authority of the representative, but the full chain of authority and where it originated.
• OCs are also B2C, helping prevent phishing by proving to customers and constituents that the company or government representative they’re interacting with really represents whom they claim to represent.
• OCs are also C2B, enabling customers and constituents to prove their identity, status, and entitlements to the businesses and governments they’re aligned with when they call in, log in, or walk in.
• OCs can prove provenance not only back to the top of an organization, but to GLEIF (described in Part 1) and/or to any other chained root of trust such as a city, state, nation, or group of nations.
• OCs can also make verifiable any other analog identifiers in addition to or instead of the LEI. For example, a national ID, regional ID, local ID, employee ID, and any other identifiers could become cryptographically verifiable with OCs (provided their inclusion is governed by rules and safeguards similar to GLEIF’s Ecosystem Governance Framework, see below).

When an authorized representative of an organization delegates some authority to a person or a thing, whether an employee, director, contractor, partner, customer, constituent, device or piece of software — no matter how many levels deep in the organization — OCs enable that person or thing to prove it digitally, instantly, securely, and globally. OCs are a game-changer.

It’s All About Authority

Delegable Authority

An organization is a hierarchy of delegated authority, from the very top to the very bottom. When a legal entity is founded it appeals to the state or other jurisdiction where it exists, which grants it the authority to organize itself and operate legally under applicable regulations and the rules of its founding documents. An org’s founding documents provide the rules by which founders and top executives relate to each other and which roles have which authority; all other roles and authority are delegated from there.

Janitors have authority to enter buildings at times or in places others cannot, and fast food workers have authority to enter the building, wear the uniform, and use the equipment. Every role within an organization, whether public or private, has some degree of authority to represent that organization, no matter how small, that can be traced back to an organization’s top representatives and founding documents. Even customers have authority to log into their accounts, enter physical or virtual venues, or have other privileges bestowed by their virtue of being a customer, with elevated privileges for highly valued customers. Contractors have authority to perform the services for which they were contracted, which sometimes include access to certain systems or facilities, and on and on.

It’s all some form of delegated authority.

In a business context this proof of delegated authority is essential for engaging in business transactions. This is the major difference compared to identity schemes for individuals. In a business context you need to prove that Stephan Wolf is GLEIF’s CEO; age, eye color, private address etc. are not needed, evidence that he’s the CEO is. Quite likely, OCs will become more important than an individual’s digital identity alone, at least in a business context.

Proof of Delegated Authority

It’s one thing to have authority, quite another to prove it. OCs enable global verification of a representative’s delegated authority — through unlimited levels of delegation — using a powerful capability of second-generation VCs: chaining.

Chaining enables multiple levels of signatures for the same credential, and also for authority to be conveyed from signature to signature and/or credential to credential, enabling the very last link in the chain of delegated authority to be as strongly provable as the first.

A janitor can prove his authority with a cryptographic chain of delegated authority in the OC he carries. When verified by someone (or something) he’s presented his OC to, the chain might look like this:

• the janitor got his authority to do X and Y from
• the facilities manager, whose authority came from
• the regional manager, whose authority came from
• the vice president, whose authority came from
• the president/COO, whose authority came from
• the CEO, who was issued a vLEI credential* by
• the Qualified vLEI Issuer (QVI)* that vetted the organization, who was qualified by
• the Global Legal Entity Identifier Foundation (GLEIF), a global root of trust for legal entity identification.

* Described below.

The authority for the janitor begins with the CEO of the organization, originating from a special root-level OC that he/she holds, and not with GLEIF or its QVI. A CEO credential received from a QVI is not a delegation of authority; it is a digitally signed, non-repudiable attestation that the holder of that credential really is the CEO, issued by an accredited QVI or other reputable issuer after a rigorous vetting process. What the CEO does with the credential from thereon has nothing to do with the fact that an external entity asserts that he/she really is the CEO, and has digitally signed that assertion so that it’s verifiable anywhere.

Roots of Trust

A “root of trust” is a verifiable ultimate source of credibility for an OC that gives downstream verifiers confidence that the OC was really issued by the claimed organization.

As discussed in detail in Part 1, GLEIF makes an ideal global root of trust, but they aren’t the only one and the need for verifiability isn’t always global: any organization or authority can become its own root of trust and start issuing OCs without asking permission from anyone else; OCs are all open source and open standard under the hood. For OCs to become broadly acceptable within a state or province, for example, the root of trust for those OCs must be broadly trusted in the physical world throughout that state or province, and it must publish a comprehensive governance framework for its OC issuance process. (More on governance frameworks below.)

When downstream verifiers trust the root of a chain, they can more easily trust the OC presented at the end of the chain. If a state or province becomes its own root of trust, the example from above could continue like this:

• the CEO’s authority came from
• the board of directors, whose authority came from
• the most recent shareholder vote, which was authorized by
• the articles of incorporation as attested by
• a legal officer of the company, whose authority came from
• the state or provincial registry of legal organizations, which
• vetted the organization and issued the credential.

Of course, the world sometimes is more complex than that and not as cleanly hierarchical, and OCs allow modeling of more complicated real-world scenarios, while still emanating from a trusted root. For example, a regional manager might be the CEO of a legal entity in Country A, but also report to a vice president of the parent company which is a legal entity in Country B. In this case, the CEO of the subsidiary would have the subsidiary’s LEI in its OC, which is linked to the LEIs of the direct and ultimate parent companies (using GLEIF lingo here). Chained OCs could easily be created to reflect this special delegation of authority, with each chain easily verifiable back to a GLEIF root of trust.

The same chaining flexibility for OCs applies to any chosen root of trust.

Binding Flesh to Digital

OCs are like ornaments on a tree: they hang from a branch attached to a trunk grown from a root. The root-level OCs are the first ones held by the organization, the highest level of authority from which all other lesser authority is delegated.

So how does the root start? How does an organization get its first, root-level OC?

The First/Root-Level OC: the vLEI

Organizational Credentials (OCs) are a specific kind of Verifiable Credential (VC), and the vLEI is a specific kind of OC, the first OC held by an organization that becomes the root of all others. So, the vLEI is an OC which is a VC. The relationships between them can be represented as concentric circles:

This means that OCs are compatible with and subject to VC standards such as those from IETF, W3C, and eventually, ISO. This also means that standards-compliant apps, wallets, and administrative tools should, eventually, work with OCs. We say “should” and “eventually” because the standards efforts are well underway but not yet concluded, and even when they are, some standards-compliant VCs and tools may not support all of the capabilities mentioned here, such as delegation (it’s possible to do OCs without delegation, but clumsy), multi-sig, key recovery, and key rotation. The OCs that will always have the capabilities mentioned here utilize second-generation VCs powered by KERI and ACDC protocols, as second-generation VCs were designed from the ground up to deliver these capabilities for organizations.

Stop! Before Issuing a Single OC…

A tree is only as secure as its root. This is why the issuance of an organization’s first, root-level credentials must be done with utmost care, with planning, preparation, and above all, security.

The open protocols underlying OCs do not force security to be done properly, but as described above, they enable the establishment of a foundational digital security posture for the organization that would be the envy of anything currently found in Web2, Web3, Web5, etc.

For example, GLEIF’s Ecosystem Governance Framework (described in the next section) recommends taking full-advantage of OC’s multi-sig capabilities by establishing signing thresholds with all root-level credentials. Otherwise, lost or compromised keys or a rogue representative at the root level could be catastrophic; it would be foolish to be exposed to this risk when avoiding it is relatively simple. These thresholds can be ‘m-of-n’, such as 1-of-2, 3-of-5, and so on, with added weighting for representatives with more authority. Sole proprietors can establish multi-sig across multiple devices, as can anyone else in a signing group.

The actual process of issuance to the multi-sig configuration of an organization must be done carefully. When a Qualified vLEI issuer (QVI) in the GLEIF ecosystem issues a vLEI, for example, it does so within a carefully orchestrated ceremony only after the organization has been fully vetted (through the LEI issuance process). Organizational representatives must also be rigorously vetted, both for their identity and their authority; a GLEIF QVI inspects company formation and other relevant documents to ensure this. Then there’s the use of secure video and audio connections, secure messaging, secure wallets, and more.

The Key to Trusting OCs: Governance Frameworks

In reviewing the draft of this post, Steven Milstein, the Vice Chair of the Governance Stack Working Group at the Trust over IP Foundation, made this insightful comment:

“OI & OCs are only as strong as their published Governance Framework. And that framework is only as robust as the technologies that implement it. The more significant the gap between the framework and the underlying code, the greater the risk [Verifiers and Issuers] assume.”

Bold words, and we agree with them. The technology underpinning OCs makes the credential verifiable, but it’s the governance framework that makes it trustworthy. The distinction is crucial:

Verifiable: can cryptographically verify four things: 1. who issued by; 2. who issued to (optional); 3. not tampered with; 4. not revoked or expired. As mentioned earlier, verification does NOT provide any judgment about the data payload inside the OC, whether it is true, correct, complete, or anything else, it only confirms who issued it and that it hasn’t been changed or revoked since issuance. The data inside could be gibberish… authentic gibberish.

Trustworthy: trustworthy means that you know and trust the issuer of the OC, and/or you trust the process by which the OC was issued because the process itself has been vetted to meet a standard that you trust. That process is a governance framework.

For example, the first governance framework for OI in existence, GLEIF’s Ecosystem Governance Framework (EGF), provides guidance for vLEI issuance, which takes full advantage of the security capabilities of second-generation VCs. How these steps are followed and by whom is critically important to ensure the process is thorough and has integrity, because the security of financial, legal and other transactions performed digitally by representatives of the organization will depend on its successful execution.

GLEIF itself does not perform any vetting of the legal entity or its representatives and is not involved in the vLEI issuance process, but through the EGF they develop and manage the detailed rules for how it all gets done, and ensure their QVIs are following those rules. It is GLEIF’s QVIs — who’ve been extensively vetted themselves by GLEIF and must remain qualified annually — who vet representatives and issue vLEI credentials. GLEIF is the global guardian and compliance officer of these governance frameworks.

OCs, Privacy, and Self-Sovereignty

Personal Privacy and Graduated Disclosure

With OCs the personal privacy of the holder — a representative of the organization — is of less relevance when that representative is an employee or contractor and they are acting within that context; the organization gets to decide what that representative should be disclosing or keeping private, which they can do quite powerfully with Graduated Disclosure as described below. When an OC holder is a customer or constituent, however, personal privacy becomes critically and legally important, magnifying the need for robust disclosure capabilities.

As with all ACDC VCs, OCs have three granular, legally enforceable “Graduated Disclosure” capabilities highly relevant to and needed by organizations:

Selective disclosure — the ability to provably disclose only some information without disclosing the rest, such as one’s authority but not their name, or their name but not their authority, or only one aspect of their authority such as their financial ceiling for signing purchase orders.

Contractually protected disclosure — when counterparties verifiably consent to the terms of disclosure prior to disclosure. The provided consent is non-repudiable, providing a path for recourse if the terms of disclosure are not honored.

Contingent disclosure — disclosure is possible only when certain conditions are met, such as keeping an identity encrypted and in a form of escrow for business purposes and interactions, but enabling that identity to be discoverable by law enforcement or regulators if it becomes necessary. Contingent disclosure solves tricky problems in telecommunications, for example, when the originator of a communication may not wish to be identifiable to network operators, but must become identifiable to authorities if their traffic turns out to be fraudulent or spam.

Self-Sovereignty

When employees or contractors are acting in representation of an organization, the org is sovereign and not the individual; there is no self-sovereignty in this situation. There is autonomy of course, as the person can choose to behave however they please regardless of rules or expectations, but not self-sovereignty. Like privacy, however, the principle changes when the representative is a customer or constituent; then the sovereignty of the OC’s holder becomes relevant. Still, the customer’s or constituent’s OC was issued by the organization and can be revoked at the organization’s discretion.

An OC’s Superpower: Traversing Boundaries

Arguably the greatest capability of OCs — and all VCs that have a sufficiently strong root of trust — is the ability to traverse boundaries of all kinds. Boundaries are the killers of identity systems, seamless interactions, and digital trust generally. OCs are ground-breaking precisely because they are boundary-breaking.

Some example digital boundaries useful to traverse:

• Geographical/political borders (between countries)
• Organizational boundaries (between companies/organizations)
• Network/software boundaries (between software and hardware networks)
• Hierarchical boundaries (any level of depth within an organization)
• Heterarchical boundaries (every boundary between systems that isn’t hierarchical)
• Communication channels (email, messaging apps, social media, calls, texts, etc.)
• Cyberspace-to-physical space* (physical-to-digital)

In each of these cases, OCs issued within one domain can be verified as authentic in another. Choosing to accept a verified OC becomes a matter of policy, not technology. For example, many countries have a national digital ID scheme, e.g. eIDAS in Europe, BankID in the Nordics, Compass and Singpass in Singapore. These schemes are incompatible with each other; in order to accept identity credentials in a cross-border fashion, participating countries must have a bespoke bilateral agreement and build bespoke technical infrastructure for each one they choose to accept, so it doesn’t happen often, with organizations ultimately suffering the most.

Such is the advantage of OCs using free and open standardized underlying protocols instead of shared platforms, even when implemented on a national scale: no bespoke agreements or technical infrastructure is required, just adoption of the same underlying standard key management, issuance, and verification protocols.

In Conclusion

As we said at the beginning, OCs enable representatives of an organization to prove their authority to represent the organization outside its boundaries to anyone, anywhere, without using identity providers, blockchains, shared platforms or other intermediaries. Never before has verifiable authority been possible across all boundaries and at global scale, and the underlying protocols that enable it are open and free to use, inviting anyone and everyone to commence as they please. A great many things are about to change, in a very positive way.

In this Part 2 we discussed the what and the why of OCs and verifiable authority, but not the how; we didn’t get technical, leaving readers to reasonably wonder exactly how all this is even possible. In Part 3 we’ll get technical by inviting the inventor of KERI key management and ACDC verifiable credentials, Dr. Samuel Smith, to explain in as business-friendly terms as he can, how OCs accomplish the things we’ve claimed in Part 2.

Stay tuned.

¹ See Crypto isn’t decentralized, Blockchain is not decentralized, and Web3 is not decentralized