Private and Public Keys

Public and private keys enable secure communication and identity verification online. Public keys encrypt data, while private keys decrypt it and sign digital documents. This system ensures privacy, authenticity, and trust across websites, emails, and transactions.

Digests

Digital digests are cryptographic fingerprints used to verify data integrity. Created by hashing algorithms, they produce a fixed-length string unique to the original content. Even a small change alters the digest, making it ideal for detecting tampering. By comparing digests, users can confirm authenticity without relying on central authorities—building trust through math.

Digital Signatures

Digital signatures ensure the authenticity and integrity of digital content using cryptographic tools. A unique digest of the content is created through hashing, then encrypted with the signer’s private key to form the signature. To verify it, the recipient recalculates the digest and compares it to the decrypted signature using the signer’s public key. A match confirms the content is unchanged and genuinely signed; a mismatch indicates tampering or an invalid signature.

DIDs and Key Rotation

Decentralized Identifiers (DIDs) and key rotation protect digital identities when private keys are compromised. Key rotation replaces old keys with new ones, and DIDs track these changes without relying on central authorities. Stored on decentralized systems, DIDs link to DID documents showing valid keys and updates—ensuring secure, self-managed identity verification.

Verifiable Credentials

Verifiable credentials are digital proofs of identity or qualifications, similar to physical documents like passports. Instead of physical security features, they use cryptographic signatures from trusted issuers to confirm authenticity. When presented, a verifier checks the credential’s digital signature against the issuer’s public key—often retrieved via decentralized identifiers (DIDs)—to confirm it’s valid and untampered. This system enables secure, private, and decentralized verification of personal claims online.

Identifiers

Identifiers are labels used to refer to things—like people, documents, or data—in both physical and digital contexts. They come in two types: assigned identifiers, given by an authority (e.g., passport numbers or student IDs), and derived identifiers, generated from the content itself using hashing algorithms. Derived identifiers act as digital fingerprints that change if the content changes, making them useful for verifying integrity. Both types are essential for organizing, referencing, and ensuring trust in digital systems.

Self-certifying Identifiers

Self-certifying identifiers are cryptographically derived identifiers that prove their own authenticity without relying on a central authority. Unlike assigned identifiers (like passport numbers), these are created by hashing content—often including a public key—so any change to the key alters the identifier itself. This makes them tamper-evident and verifiable. Used in systems like Decentralized Identifiers (DIDs), they enable secure, trustless identity verification by embedding cryptographic trust directly into the identifier.

Where DID Documents List

DID Documents—files that describe public keys, authentication methods, and service endpoints—can be stored in various ways depending on the DID method. Some methods store them on blockchains for immutability (e.g., did:indy), others use content-addressable systems like IPFS (did:ipfs) for tamper-evidence. Web-hosted DIDs (did:web) are easy to publish but rely on website control. Event-log-based methods like did:keri track changes over time, while peer and key-based DIDs share data directly or derive it from keys for lightweight, private use. Despite different storage models, all resolve to a standard W3C DID Document, ensuring interoperability across systems.

Resolving a DID

Resolving a Decentralized Identifier (DID) means converting it into a DID Document containing public keys, service endpoints, and metadata for secure interactions. The resolution process varies by DID method. Some, like did:web, use domain-based URLs and HTTPS to fetch the document. Others, like did:indy, query blockchains to reconstruct the document from signed operations. Lightweight methods like did:key generate the document locally from embedded key material, while did:peer involves direct exchange between parties. Hybrid approaches may store document digests on-chain for tamper-evidence. Despite different resolution models, all produce a standard W3C DID Document, ensuring interoperability and trust.

Detecting DID Document Duplicity

Detecting duplicity in DID documents is crucial for maintaining trust in decentralized identity systems. Since DID controllers can update their documents—including public keys—malicious changes may go unnoticed if not externally monitored. To prevent this, some DID methods store documents or their cryptographic digests on tamper-resistant public ledgers (e.g., did:indy, did:ipfs, or Ethereum), making unauthorized changes detectable. Others, like did:keri, use decentralized networks of observers to track and verify document history. These external verification mechanisms ensure that any attempt to alter identity records without accountability can be identified, preserving the integrity of the system.

Control of DID document data

A DID resolves to a DID document with keys, endpoints, and metadata — but who controls updates depends on the DID method. The DID Core spec doesn’t define update rules, so methods vary. Some, like did:web or did:peer, rely on a controller field but offer no verifiable history. Others, like did:indy or did:btcr, anchor changes on blockchains, while did:ipfs uses content-addressed hashes to detect tampering. Methods such as did:webvh or did:scid maintain tamper-evident logs, and static ones like did:key can’t be updated at all. In short, while all DID methods yield valid DID documents, only some provide cryptographic proof of legitimate updates — making your choice of DID method critical for trust.

Passwords and keys

Passwords are fragile because they can be stolen or leaked. Keys improve security by keeping your private key secret and proving identity with cryptographic signatures. Decentralized Identifiers (DIDs) take it further — instead of sharing just a key, you share a DID that resolves to a DID document with your public key, enabling mutual authentication and secure key rotation. Together, keys and DIDs offer a stronger, phishing-resistant future for online trust.

Keys in DIDs

Resolving a DID gives you a DID document containing cryptographic keys. These keys can authenticate you, sign trusted claims, enable encrypted communication, or delegate and invoke rights. By assigning different keys to different tasks, a DID becomes more than just an identifier — it’s a versatile toolkit for trust, privacy, and authority in decentralized systems.

Authentication keys of DIDs

DIDs resolve to DID documents, which include authentication keys. Instead of passwords, you prove your identity by showing control of a private key that matches a public key in your DID document. This makes authentication secure, verifiable, and flexible — putting identity control in the hands of the DID subject or trusted delegates.

Assertion keys of DIDs

DIDs resolve to DID documents, which describe the subject and include cryptographic keys. Assertion keys in a DID document let an issuer sign data like verifiable credentials. Anyone can then resolve the issuer’s DID, retrieve the document, and verify the signature against the public key. This makes trust portable, allowing credentials to be checked anywhere without relying on a central authority.

Key agreement keys of DIDs

Key agreement keys in a Decentralized Identifier (DID) document enable encrypted communication between two parties. When someone wants to send you a secure message, they resolve your DID to find your public key agreement key and use it to create a shared secret — a cryptographic handshake that ensures only you can decrypt the message with your private key. Built on algorithms like Diffie–Hellman, this process lets two parties establish a private, verifiable connection without ever meeting first. In short, key agreement keys make DIDs not just about identity — but about secure, confidential communication between trusted parties.

Multiple keys

In digital identity, relying on a single cryptographic key creates a single point of failure. Multisignature and threshold key schemes solve this by dividing control among multiple keys, requiring several to sign or approve an action. In a DID document, this allows for flexible arrangements — for example, two out of three keys might be needed to issue a credential, or both a user’s and an organization’s keys must confirm control. This approach greatly reduces the risk of compromise and supports shared responsibility, though it adds coordination complexity. The result is a stronger, more resilient foundation for identity and authorization.

Key pre-rotation

In digital identity systems, key pre-rotation strengthens security by protecting against key compromise during rotation. Normally, a private key is paired with a public key published in a DID document so others can verify your identity or signatures. If your private key is stolen, an attacker could impersonate you — or even rotate the key to seize control of your DID. Pre-rotation prevents this by generating the next key pair in advance and publishing only a cryptographic digest of the future public key. When rotation occurs, the real key is revealed and verified against that digest. Even if your current key is compromised, the attacker can’t predict or replace the next one. While not all DID methods support pre-rotation, those that do make key management safer, ensuring continuity and resistance against identity hijacking.

DID service endpoints

When you resolve a Decentralized Identifier, or DID, you get more than just cryptographic keys — you also get service endpoints. These act as contact points that show where and how others can reach you, like for messaging or credential exchange. While DIDs don’t route messages themselves, service endpoints link your decentralized identity to real-world networks such as the web or peer-to-peer systems. In essence, your DID proves who you are, and service endpoints show how to connect with you.

Where do you store private keys

When you create a Decentralized Identifier, or DID, you get a public and private key — and keeping that private key safe is critical. You can store it on the edge (like your phone or hardware wallet) for full control, or in the cloud for easier recovery if your device is lost. Edge storage offers security and independence, while cloud storage provides convenience and backup. Many wallets use both: your key stays on your device but is backed up securely in the cloud. However you store it, your private key is your identity — lose it, and you lose control of your DID.

Hybrid storage and social recovery for private keys

When you create a Decentralized Identifier, or DID, protecting your private key is everything — lose it, and you lose your identity. Hybrid storage helps balance safety and recovery by storing your key securely on your device while backing it up in the cloud, encrypted so only you can access it. To go further, social recovery lets you split a recovery key among trusted friends or devices, requiring a few shares to restore access. Together, hybrid storage and social recovery make DIDs both secure and recoverable — practical for everyday use without sacrificing control.

Trust Registries: Whose DID is it, anyway?

Decentralized Identifiers, or DIDs, use public keys to let people or organizations prove who they are and sign verifiable credentials. For example, if Alice claims she has a degree from Acme University, you can check the credential’s signature against Acme’s DID document to verify it. But what if someone creates a fake Acme DID and issues look-alike credentials? Cryptography alone can’t tell you which one is real. That’s where governance and Trust Registries come in. A Trust Registry lists verified DIDs endorsed by recognized authorities, helping you confirm which entities are legitimate. This combination of cryptographic proof and governance trust ensures that decentralized identity is not only verifiable, but also trustworthy.

Protecting Private Keys

Private keys are the foundation of a Decentralized Identifier, or DID — they’re what prove you’re really you. There are three ways to store them. Clear storage keeps your key directly on your device: easy to use, but risky if someone gains physical access. Encrypted storage locks the key behind a password, PIN, or biometric, so a stolen file is useless without the decryption secret. The most secure option is a Hardware Secure Module, or HSM — a dedicated chip where your key is generated, stored, and never allowed to leave. All cryptographic operations happen inside the HSM, and tamper-resistant features can automatically erase the key if the hardware is probed. Modern smartphones and cloud providers offer equivalent protection through built-in secure enclaves and Trusted Execution Environments. Whatever the form, the goal is the same: keep your private key secure and solely under your control — because whoever holds the key holds the identity.

What is Governance

Governance is the set of operations intended to mitigate risks by holding actors accountable to a set of rules or laws — and it shows up everywhere. A governance system typically includes a governing body that identifies risks and creates rules, a conformance scheme to enforce them, actors expected to follow them, and arbiters who ensure they do. In government, legislators write laws and courts enforce them. In standards organizations, governing bodies publish requirements and auditors verify compliance. In sports, rule commissions define the game and referees enforce it. At home, parents set family rules and use rewards or consequences to hold children accountable. In all these forms, governance is how humans create order, trust, and fairness — turning chaos into systems that function predictably. Future Bite-Sized Trust videos will take a closer look at each of these elements in turn.

Players in a governed ecosystem

Every governed ecosystem relies on a cast of actors working together to manage risk and maintain trust. The Governing Body is the recognized authority that creates the rules, sometimes appointing an Administering Authority to handle day-to-day operations. Governed Parties are those who agree to follow the rules — citizens, companies, students, or players depending on the context. Arbiters check that the rules are actually followed: police and judges in government, auditors in standards organizations, referees in sports, teachers in schools. And Relying Parties are those who depend on everyone else doing their part — consumers trusting safety standards, investors trusting the rule of law, fans trusting a fair game. Together, these actors form the human infrastructure of governance: the foundation of fairness, accountability, and trust that allows any system to function.

How Governance Ecosystems Assesses Risk

Governance exists to reduce the risks a community can actually control — but that requires first identifying which risks matter. Risk is the chance that something unwanted happens, assessed along two dimensions: how likely it is, and how severe the outcome would be. These are rated on simple scales and combined into an overall risk score, often visualized as a grid. Because no governance ecosystem can address every problem, anything below a set threshold — typically medium risk — is set aside, focusing time and resources where they count most. The specific risks vary by context: public safety and fraud in government, security and compliance in business standards, injury or unfair play in sports, missed deadlines or poor grades at home. Only after identifying which risks are worth tackling does a governance ecosystem decide whether rules, standards, or laws could realistically reduce them to an acceptable level — and design its requirements accordingly.

How do Governance Ecosystems Develop Requirements

Governance requirements grow from four core ideas: risk, mandate, suitability, and leverage. Risk is the starting point — identifying what collective actions are needed to reduce an unacceptable outcome. Mandate ensures rules have teeth — optional guidance rarely works, so effective requirements use clear language like “must” and “shall.” Suitability asks whether a rule will actually work in practice: is it affordable, enforceable, and realistic given the abilities and motivations of those expected to follow it? Leverage avoids reinventing the wheel — before writing a new rule, it’s worth asking whether an existing one already solves the problem reliably. When all four elements are considered together, governance ecosystems can produce requirements that are practical, clear, and genuinely effective at building trust and safety.

How Conformance Schemes Work

Governance isn’t just about making rules — it’s about ensuring people actually follow them over time. A conformance scheme starts with a clear, public set of rules and a list of conformance criteria: the documents, measurements, or demonstrations that show compliance. Criteria must be realistic to gather, or people simply won’t comply. Schemes also vary in how much confidence they require — ranging from a simple self-declaration to a thorough independent review. Some systems formalize this as levels of assurance, where higher levels demand more evidence and more scrutiny. Trained arbiters — certified auditors, umpires, inspectors — review the evidence by observing, checking documents, and applying whatever methods fit the context, then issue a report identifying any problems and required fixes. Serious non-conformities can trigger further action, including removal from the ecosystem. That may sound harsh, but it’s what keeps the system trustworthy and fair for everyone who depends on it.

What Trust Registries Do

Trust registries aren’t new — business registries, the Yellow Pages, and certification boards all served the same basic purpose: helping people figure out who they could rely on. In the digital world, trust registries play the same role, just machine-readable and designed for automated systems as well as people. A trust registry is a directory, backed by a recognized authority, listing the organizations, systems, or agents that have met the requirements of a conformance program within a governance ecosystem. They answer two key questions: is this entity authorized to do a particular thing under a given governance framework, and do different ecosystems recognize each other’s rules and roles? To support this, Trust Over IP created the Trust Registry Query Protocol — a standard way for anyone, or any software agent, to query these registries and get reliable answers. Good governance also requires clear rules about how entries are added, suspended, or removed. As digital ecosystems grow more decentralized, trust registries remain the foundation: an authoritative, queryable system of record that gives organizations and systems the data they need to make their own trust decisions.

Zero Knowledge Proofs

When Alice shows her driver’s license at a bar, she reveals far more than necessary — her full birthdate, exact age, and home address — just to prove she’s old enough. Digital credentials can make this worse, since unlike a physical ID that’s briefly glanced at, a digital one can be copied and stored perfectly. A third-party verification service doesn’t solve the problem either; it just shifts who learns everything about Alice. What’s needed is a way to prove one specific fact — “I’m over the legal age” — without revealing anything else, and without producing proof that can be saved or reused. That’s what zero-knowledge proofs make possible. Using probability and advanced cryptography, a zero-knowledge proof lets Alice prove a claim is true while sharing nothing beyond that single fact. The verifier gets confidence that Alice meets the requirement; Alice keeps everything else private. Zero-knowledge proofs are becoming a key tool for minimizing data sharing while maintaining full trust.