Open format, closed service

The constitution#

Specification v0.2 opens with a split it calls the constitution. Quoted, not paraphrased:

OPEN (published, versioned, reproducible by anyone): Grant semantics · Proof format · protocol verification rules · Receipt format · Outcome Attestation format · portable identity model.
DELEGUS (the service): issuer trust · live verification (replay, revocation freshness) · evidence preservation · decision signing · adapter network · outcome graph · risk models · economic assurance.

Everything a receipt means is on the open side. Everything that requires someone to be on duty — knowing which issuers are real, remembering which proofs have been seen, keeping the evidence, signing — is on the service side. The rule that ties them together is the fifth design constraint:

Someone must be able to verify a Delegus artifact without calling Delegus.

What "open" concretely means here#

The specification is published, frozen, and versioned. v0.2 is the sole normative text. It is served as the v0.2 specification and kept permanently under a versioned path. Changes after the freeze are numbered errata, each stating the sections it touches, what changed and why, or a new version. Two errata exist; both are on the errata page with their reasoning. Nothing is edited in place.

The rules are a document with a hash. The twenty protocol checks, in their fixed evaluation order, are the profile delegus-base-v1, served byte for byte. Its SHA-256 appears in every receipt as protocol.profile_hash. You are never verifying against "the rules"; you are verifying against those bytes, and the receipt says which.

The formats are standard. Grants are Verifiable Credentials signed as JWS. Proofs are per-request Ed25519 signatures bound to one grant, one recipient, one canonicalized action and one moment. Receipts are compact JWS. Canonicalisation is RFC 8785. Identity is did:web for organizations and did:key for agents — DNS, HTTPS and Ed25519, nothing else. The specification's first design constraint is that an ordinary backend engineer can implement the protocol layer with a standard JOSE library, and that constraint was enforced on the reference engine, which has no runtime dependencies.

The reference engine and SDK are Apache-2.0. @delegus/core is the pure engine: it takes the artifacts, the evidence snapshots and the clock as inputs, performs no I/O, and returns the decision. @delegus/sdk wraps it with the client and the delegus CLI. Both carry the Apache License 2.0. Both are published on npm: @delegus/core and @delegus/sdk.

text

npm install @delegus/sdk

Conformance is a test suite, not a promise. The engine ships a conformance suite: fixed test keys, a fixed clock, and non-production identifiers; three ALLOW paths and one DENY vector for every reason code in the specification, plus sets for htu normalization, RFC 8785 canonicalization and jti format. Every vector is reproducible byte for byte on any platform — Ed25519 signing is deterministic and even the status-list gzip encoding is pinned to a fixed pure-JS encoder so the bytes never drift between zlib versions. A third-party implementation reproduces expected from input. Delegus does not claim conformance for anything that does not pass every required vector.

Every receipt is re-verifiable without Delegus. Given a receipt, the published receipt public key, and the four evidence artifacts the receipt names by hash, anyone re-runs the profile with the receipt's own signed evaluated_at as the clock and confirms the protocol result. This is covered in detail in the receipts post; the point here is that it is on the open side of the line, by design, and tested.

What "closed" concretely means, and why#

The service is proprietary and run by Delegus, and that is part of the design.

Issuer trust. Someone has to decide that did:web:acme.com really is Acme, that the domain proof happened, that a key reported compromised is not honored. That is a registry with a human process behind it, and it is an accountable party's job.

Liveness: replay and revocation. A proof must be accepted exactly once, anywhere. A revocation, once acknowledged, must be seen by every later verification, anywhere. v0.2 makes both normative. Those are properties of a single coordinated service, not of a format; a federation of independent verifiers cannot promise either. The receipt's trust block records Delegus's attestation of these checks, and the spec is explicit that this block is not reproducible by design — you verify that Delegus signed it, not that you could have computed it.

Evidence preservation. Everything a receipt references stays retrievable by hash for seven years, as v0.2 specifies. The production store is designed around S3 Object Lock in compliance mode so that nobody, Delegus included, can delete or alter it inside the window. Preservation is an obligation someone has to carry for seven years; a protocol cannot carry it.

Signing. Receipt keys live in AWS KMS and never leave it; the public halves are published in the DID document. Rotation adds a key and never removes one, so old receipts keep verifying. Only Delegus holds the private keys, and that is what "only Delegus can produce a fresh artifact" means in practice.

Why draw the line this way#

Three reasons.

Because verification has to outlive the vendor. A receipt for a purchase made in 2026 may be the deciding document in a dispute in 2031. If verifying it required Delegus's API to still exist, still be reachable, and still agree, the receipt would be a promise, not evidence. Putting the format, the rules and the re-verification procedure on the open side means the receipt stands on its own with a public key and four blobs.

Because "fail closed" and "deterministic" are only credible if you can check them. The specification says unknown, missing, ambiguous or unavailable inputs produce DENY, and that the same inputs and snapshots give the same result anywhere. Those are strong claims. The conformance suite is how they are made checkable rather than asserted, and it only works because the engine is a pure function you can run yourself.

Because the service's value is exactly what can't be open. Being on duty — knowing who is real, remembering every proof, keeping every byte, signing with keys nobody else has — is what a relying party pays for. Giving the format away does not give that away. It makes it worth more, because every decision Delegus signs is one anyone can audit.

What this is not#

It is not a foundation, a consortium, or a chain. There is one specification, one accountable operator of the service, and one place the private keys are. It is not "open core" in the sense of a crippled free version: the open engine is the whole protocol layer, and it is the same code the service runs. And it is not a claim that the format will never change: it will, through numbered errata and a v0.3, in public, with every old receipt still verifying against the version that produced it.

The licensing is stated in the specification's own header, as non-normative metadata that changes no normative text, no profile document and no trust-configuration descriptor: the specification text is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0); the reference engine @delegus/core, including its conformance vectors, and the SDK @delegus/sdk are licensed separately under Apache-2.0; the service is proprietary. Short form: specification text CC BY 4.0, reference engine and SDK Apache-2.0, service proprietary.