Decentralized identifiers

identity
Online identity today is issued and controlled by platforms; a decentralized identifier is one you own and can prove, and it is what would keep the federation’s discovery open while access stays gated.
Author

Chris Sweet

Published

July 18, 2026

The problem, and what a DID is. Almost every identity you have online is issued and controlled by someone else. You “log in with Google,” your university account is created and revoked by IT, your GitHub identity belongs to GitHub. Convenient, but your identity, and everything attached to it, lives at the mercy of that platform: close the account and it is gone. A decentralized identifier (DID) inverts that. Defined by a W3C standard (a Recommendation since 2022), it is an identifier of the form did:method:something that you create and control with a cryptographic key, and that resolves to a small public document (the DID document) listing your keys and service endpoints, where to reach you, with no company or registry needed to issue it or vouch for it. That is the core of self-sovereign identity: the identifier is yours, portable, and no one can take it away by closing an account.

The simplest method, did:web, needs no blockchain at all: the identifier did:web:compchem.example.edu just resolves to a JSON file served at https://compchem.example.edu/.well-known/did.json:

{
  "id": "did:web:compchem.example.edu",
  "verificationMethod": [{
    "id": "did:web:compchem.example.edu#key-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z6MkhaXgBZD..."
  }],
  "service": [{
    "type": "KnowledgeBundle",
    "serviceEndpoint": "https://github.com/compchem/wiki"
  }]
}

Resolving the DID hands you a public key (to check the holder’s signatures) and a service endpoint (where their bundle lives), with no registry in the loop.

DIDs travel with verifiable credentials. A verifiable credential is a cryptographically signed claim, a digital diploma, a driver’s license, or “this holder is a current faculty member”, following an issuer / holder / verifier model: an issuer signs it, you hold it, and any verifier checks the signature against the issuer’s DID without contacting the issuer. Trust is in the signature, not a central database.

Why it matters here. Today the federation’s discovery leans on a curated index and access on a GitHub credential, both tie identity to one platform’s account. DIDs make that identity portable, the fourth leg of “locked in on nothing” alongside a portable agent, memory, and tools. Concretely they do three jobs: a stable identifier that survives moving hosts (the “findable” part of FAIR, the Findable-Accessible-Interoperable-Reusable data principles, done without a central issuer); service endpoints in the DID document that double as a discovery primitive (resolve one identifier, get pointers to a participant’s catalog, agent card, and endpoints); and a trust anchor, a verifiable credential checked against a DID gates consumption while discovery stays open. A DID document is itself RDF, so identity, description, and discovery land in one graph rather than three systems.

Honest status: design and a plan, not something built. The cheapest test is did:web (the simplest DID method, where the DID document is just a file on a normal web domain, no blockchain) on the existing GitHub Pages, to prove portability before spending anything heavier.

Sources