Why This Exists

Not everything needs to be public to be verifiable.

Some work is published for everyone. Some is shared with a few collaborators, a membership, or a private group. That choice should not decide whether the work's signed history can be checked independently.

The DFOS Protocol separates the record from its delivery. A signed commitment circulates without the document it names. An application checks a signature without asking the original host to vouch for it. A reader who does receive the document checks that the bytes match the commitment.

The purpose is not to eliminate hosting. It is to make hosting a service rather than the only place the evidence can be examined.

Identity That Continues

A DFOS identity begins with a signed operation, not a registration in a directory. The did:dfos identifier derives from that genesis operation, so re-deriving it from the chain is the check: a chain that does not derive the identifier it claims is rejected, whatever served it. Later operations change the identity's keys and services without changing the identifier, and every key that resolves proves possession of itself, bound to its role and its position in the chain.

An application verifies a sign-in against that signed history rather than against an account at one host. A domain you control can point to the identity, with a matching claim recorded on the identity itself.

The reference platform holds a signing key for every account by default, so ordinary use needs no key management. You can add keys the platform never holds. A controller key you hold is a fork right: from the last operation it controlled, you can continue the same identity on another relay, and who follows you there is a choice of relay. Any controller key can change the key set, the platform's included, and every change is a signed operation on the chain where anyone reading it can see it.

Permissions You Can Delegate

Authorization is a signed credential, not a session at one service. A credential names the identity it authorizes and the resources and actions it covers. Delegation is linear and narrowing: each hop can drop resources, drop actions, and shorten expiry, and it can never widen what it was given.

For credential-gated API calls, the recipient proves possession of its own key and binds that proof to the particular request, so a captured credential authorizes nothing without the audience key. A credential expires at the time it names and can be revoked before then, and a verifier enforces a revocation once it holds it.

Where the Guarantee Stops

Verification establishes who signed a record and whether a document matches its commitment. It does not establish that a signed claim is true: the chain shows what was signed, never who was at the keyboard.

An identity chain is linear per view. A relay admits the first successor it sees at a position and refuses later ones, nothing in this corpus arbitrates between relays that admitted different successors, and which relay you read is which view you get. A signature proves who signed, forever, from anywhere. Whether a key is still effective, and what the head is, are statements about the freshest state a relay has.

The protocol does not encrypt. A relay operator reads every blob it stores, and nothing obliges any relay to keep your chain: keep your own copies of your chain and your documents. Guarantees states the full boundary in one page.

Privacy Considerations

The public record contains signed commitments and identity metadata. It does not need to contain the underlying document.

The protocol commits to a document via an unsalted dag-cbor → SHA-256 CID. The commitment binds; it does not hide. Anyone holding the CID can test a candidate document against it and learn whether the guess was right, so a document drawn from a small or guessable space is not confidential against a party that holds its CID, and two chains that committed the same bytes are visibly the same bytes. Confidentiality of the documents themselves is enforced above the protocol, by whoever serves them. There is no end-to-end encryption here, and the security posture of a document is the security posture of the party serving it.

What the Protocol Is

The DFOS Protocol specifies how Ed25519 signed chains establish identity, commit documents, and produce proofs. It defines identifiers derived from a genesis operation (did:dfos), content-addressed commitments via CID, and a relay network of verifying HTTP endpoints that each re-verify what they distribute. Which view of an identity you follow is a choice of relay.

Identity chains carry an optional discovery vocabulary: controller-signed services that say where to reach an identity and what stable content it anchors, projected into verified identity state alongside its keys. Witnesses can attach a standalone countersignature to any CID-addressable operation, carrying an optional open-namespace relation tag (endorses, coauthors, witnessed) that names the nature of the attestation.

Verification is a function of the chains. A signed chain, the identity chains it names, and the revocations the verifier holds give valid or invalid. The signature check is one step of that: a verifier also needs canonical dag-cbor encoding, SHA-256, the identifier derivation, the chain rules, and, where authorization applies, the delegation walk. Standard cryptographic components are enough, and no DFOS software is required. There is no registry to query and no blockchain to sync.

The reference implementation is in TypeScript. Cross-language verification exists in Go, Python, Rust, and Swift, all running against the same deterministic test vectors from the specification.

What It Isn't

Design Principles

Status

The specification iterates in place and carries the version of the release it ships with. The cross-language test vectors ship with each release, and every implementation is checked against them. It is open source under the MIT license. The DFOS platform runs on it in production. It has not been submitted to a standards body.

The executable suites in packages/protocol-verify and packages/relay-conformance are the conformance definition. The CLI ships pre-built binaries for Linux, macOS, and Windows, installable via Homebrew, Docker, or a single curl command.

Discussion happens in the DFOS space. Read the full specification, read what the protocol guarantees and does not, explore the FAQ, or browse the source on GitHub.