The Building Blocks

Learn the foundations we used to build Verana: DIDs, Verifiable Credentials, and Trust Registries.

Problem Statement: Trust at Internet Scale

We want portable, verifiable trust between parties that don’t share a database or a single identity provider. The Web’s default identifier (the URL) ties trust to DNS, certificate authorities, and domain control: great for content addressing, fragile for entity addressing (people, orgs, services, agents).

We need identifiers that are cryptographically bound to controllers, interoperable across ecosystems, and work offline. We need a way to attach verifiable claims to those identifiers, prove them selectively, and check who’s authorized to issue/verify them. That’s what DIDs + VCs + Trust Registries provide.

1) Decentralized Identifiers (DIDs)

A DID is a globally unique identifier (URI) whose ownership is proven cryptographically, not by a central registry. Example:

did:web:example.com

1.1 DID Document (the metadata for a DID)

Resolving a DID returns a DID Document: a small JSON object describing public keys, verification relationships, and service endpoints controlled by the DID’s controller.

{
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "#keys-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
    }
  ],
  "authentication": ["#keys-1"],
  "assertionMethod": ["#keys-1"],
  "service": [
    {
      "id": "#agent",
      "type": "DIDCommMessaging",
      "serviceEndpoint": "https://agent.example.com"
    }
  ]
}

Why DIDs > URLs for identifying entities:

  • Self-certifying control: Proof of control comes from possession of the private key corresponding to keys in the DID Document, not just control of a domain or account.
  • Key agility: Rotate keys and add multiple keys/relations without changing the DID.
  • Transport agnostic: Works online/offline and across transports (HTTP, DIDComm, Bluetooth, QR, NFC).
  • Method choice: Different DID methods offer different root-of-trust models (web, event logs, ledgers, etc.).

Takeaway: did:web is the easiest on-ramp; did:webvh/did:webs add provable key history and stronger assurances; did:ebsi aligns you with EU trust frameworks.

2) Examples of DID Methods You'll Meet in Verana Ecosystems

A DID’s first path segment is its method (e.g., did:web:…). Methods define how DIDs are created, resolved, and updated.

2.1 did:web — leverage DNS + HTTPS

How it works:

Host a DID Document under a domain you control (e.g., https://example.com/.well-known/did.json).

Pros:

Simple, deployable today, integrates well with existing web ops; good for organizations and services.

Cons:

Trust ultimately rooted in DNS and Web PKI; no built-in verifiable key history.

When to use: Public-facing services, developer portals, early integrations, discovery via the web.

2.2 did:webvh — did:web + verifiable history

Idea:

Keep the operational convenience of did:web but add a verifiable key/event history so resolvers can audit control changes over time.

Pros:

Mitigates did:web’s weakest point (unverifiable history & compromises) while keeping compatibility with web tooling.

Cons:

More moving parts than plain did:web.

When to use: Enterprises and ecosystems needing web-based identifiers with historical accountability and stronger assurance.

2.3 did:webs — web-anchored, secured by key event logs

Idea:

A web-discoverable DID whose trust is rooted in cryptographic key events (not DNS/CA). Built on KERI event receipts.

Pros:

Stronger independence from DNS/CA operators; verifiable key rotation history.

Cons:

Newer method; requires event-log infrastructure.

When to use: High-assurance use cases that still want web discovery.

2.4 did:ebsi — DIDs in the European EBSI ecosystem

Idea:

EBSI provides DID methods and registries for EU trust ecosystems (e.g., accredited legal entities). DID Documents are registered and governed per EU rules.

Pros:

Alignment with EU trust lists, accreditation, and conformance tooling; clear governance.

Cons:

Tied to EU frameworks and onboarding processes.

When to use: Interop with EU public-sector and EBSI-compliant ecosystems.

3) W3C and Anoncreds Verifiable Credentials (VCs)

A Verifiable Credential is a tamper-evident package of claims that an issuer makes about a subject (identified by a DID or another identifier). A Verifiable Presentation (VP) is a holder-curated bundle of one or more credentials/derived proofs presented to a verifier.

3.1 Anatomy (minimal JSON example)

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "EmployeeCredential"],
  "issuer": "did:web:acme.example",
  "credentialSubject": {
    "id": "did:web:alice.example",
    "employeeId": "E-12345",
    "role": "Engineer"
  },
  "validFrom": "2025-01-01T00:00:00Z",
  "credentialStatus": {
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "4242",
    "statusListCredential": "https://acme.example/status/employee-2025.json"
  },
  "proof": { /* Data Integrity or JOSE/COSE proof */ }
}

3.2 The Trust Triangle

Diagram illustrating the issuer-holder-verifier trust triangle

Issuer

(e.g., a company, university) signs a VC.

Holder

(person, org, service, or AI agent) stores it in a wallet/agent and creates a VP when needed.

Verifier

Checks the cryptographic proof, the credential’s schema, its status, and whether the issuer is authorized for that schema in the relevant trust registry.

3.3 Why VCs enable privacy-preserving data sharing

Selective disclosure:

Share only the claims necessary (e.g., age over 18) using cryptosuites like BBS+ or formats like SD-JWT VC, or using Anoncreds.

Unlinkability:

Derived proofs prevent verifiers from correlating different presentations (Anoncreds).

Pairwise identifiers:

Use different DIDs per verifier to avoid cross-domain correlation.

Revocation at scale:

Status List credentials enable privacy-preserving revocation checks without calling home on each presentation.

3.4 Crypto options you'll see

Data Integrity proofs (JSON-LD; pluggable cryptosuites like BBS+ for selective disclosure and predicates).
JOSE/COSE proofs (JWT/JWS, SD-JWT, COSE) for familiar JOSE/CBOR stacks.

4) Trust Registries and Decentralized Trust Networks

A Trust Registry (aka “trust list”) publishes authoritative mappings such as schemas, authorized issuers, and authorized verifiers.

4.1 What is a Trust Registry?

Schemas

Machine-readable definitions of credential types.

Issuers

Which entities are authorized to issue which schemas (under what accreditation).

Verifiers

Who can request/verify particular schemas and for what purpose.

Policies & governance

Links to the Ecosystem Governance Framework (EGF) that defines rules, evidence, liability, and audit.

4.2 Why registries are necessary

Automatable trust decisions:

Verifiers need to know, programmatically, whether an issuer is legitimate for a credential type.

Interoperability:

Common schemas + canonical issuer lists enable multi-vendor, multi-jurisdiction networks.

Privacy-preserving business models:

Authorization checks occur against ecosystem policy—not by centralizing user data. Users disclose minimal claims; verifiers check issuer authorization against the registry.

4.3 Examples and patterns

EU/EBSI

Maintains Trusted Issuers and Trusted Schemas registries; credentials reference status lists and schema URIs.

ToIP

Defines a Trust Registry Query Protocol (TRQP): a simple, DNS-like API to ask: “Does entity X hold authorization Y under governance Z?”

National ecosystems

Sector regulators, notarial colleges, or accreditation bodies publish registries to synchronize authorization lists across hundreds of participants.

Ready to Build with Decentralized Trust?

Now that you understand the building blocks, explore how Verana implements these technologies to create the open trust layer for the internet.

Explore Verana Technical Documentation