Summary: DeDi is best understood not as a generic identity product or a simple registry-hosting service, but as a lower-layer protocol for discovering and verifying public information from authoritative registrars. Its primary materials describe an open specification and reference effort for exposing public directories—such as public keys, revocation lists, sanctions lists, membership lists, licenses, and other source-of-truth records—through a unified lookup/query interface with cryptographic verification, provenance, and update semantics. The reusable mechanism insight is that DeDi separates namespace ownership, directory schemas, record publication, lookup APIs, signature verification, revocation/update signaling, and optional hosted infrastructure into a comparison-ready trust-directory stack.
What it does:
Defines a common protocol for publishing and querying public registries across organizations and jurisdictions
Organizes public data around namespaces, directories, and records rather than around one application-specific schema
Targets machine-readable lookup of public keys, memberships, licenses, revocations, sanctions, and other positive/negative lists
Emphasizes signed responses, provenance tracking, tamper resistance, and current-state verification instead of static document download
Plans or supports security features such as signed directory manifests, integrity checks, revocation notifications, key rotation workflows, and client-side caching/lookup libraries
Offers a hosted implementation path through dedi.global while positioning the protocol itself as open infrastructure rather than a closed product
Key claims:
The README is explicit that DeDi is trying to solve the high cost of validity and authenticity checks across fragmented public registries. Its core move is not identity in the abstract, but standardizing access to authoritative public information.
The strongest analytical split is the namespace / directory / record model. That decomposition makes DeDi useful for comparing who controls publication, which schema is canonical, and how downstream systems decide what counts as a trusted source.
The LF Decentralized Trust Labs page is especially useful because it makes the intended lower-layer protocol surfaces explicit: URI and payload semantics, security mechanisms, signed manifests, revocation notifications, key rotation, lookup clients, caching, and interoperability tooling.
The public site’s DNS for trust framing is helpful because it clarifies the ambition: one lookup path for many registries, with cryptographic verification attached to responses rather than bespoke bilateral integrations for every verifier.
DeDi is also notable for its coexistence model. The materials say it can sit alongside existing registries and multiple data standards, which makes it a middleware and publication-layer comparison point rather than a rip-and-replace application.
The hosted dedi.global path introduces an important control-surface question of its own: how much practical authority sits in the protocol versus in the operated platform, governance committee, replication layer, and default infrastructure that publishers and verifiers actually use.
DeDi belongs in the corpus because it gives the identity/registry cluster a useful comparison point for source-of-truth publication, signed public-key and revocation discovery, registry interoperability, and machine-readable trust establishment—especially for systems where the real bottleneck is not credential issuance but discovering who or what should be trusted right now.
Whitepaper: No canonical standalone DeDi whitepaper surfaced in this pass. The strongest primary materials were the protocol README, the LF Decentralized Trust Labs lab page, and the public dedi.global overview collected in ../whitepapers/dedi-primary-sources-2026-05-13.md.