Colophon Record

An instrument of the
Objects of Affection Collection

Standards & the open reference implementation

Built on open standards, so the proof does not depend on us.

Colophon's identity and credential layer is not a private format. It is a working, open reference implementation of the same standards the world is converging on for digital identity, verifiable credentials, and product passports. An object's accountability record is issued as a W3C Verifiable Credential, bound to a decentralized identifier that anyone can resolve, and signed with a public key you can pull straight from our published DID document. You can verify one of our credentials with off-the-shelf tooling and no access to our database. That independence is the point.

Evidence infrastructure, not certification. Conformance to a standard describes the format of our records. It is not a certificate of authenticity for any product, and it is not a claim of full, final Digital Product Passport compliance.

What Colophon implements

Open standards, each pinned to its published specification.

These are the specifications our identity and credential layer follows. The list below is the human-readable version of a live, machine-readable report served at /standards/conformance, which any developer or auditor can read directly.

The specification we publish

Lacuna: a published specification for provenance records with declared absence.

The standards above are ones Colophon Record follows. This one we wrote and published.

A colophon is the printer's mark at the end of a book. It states who made the thing, and how. A lacuna is the declared missing portion. It states what is absent. Colophon Record is the instrument. Lacuna is the specification it writes to. One records what is known about an object's making and custody. The other governs how a record says what it does not know.

Why it is built this way

Independent, verifiable, and ready for the passport era.

The reference, in the open

A credential, an identity document, and a passport export.

These are the real shapes Colophon issues. The credential below is shown decoded (a VC-JWT is this JSON, base64url-encoded and EdDSA-signed). Nothing here is minted, tokenized, or transferable: a credential is a signature over a hash, and the authenticity attestation is a separate record the brand controls.

The Verifiable Credential (decoded VC-JWT payload) 
{
  "iss": "did:web:objectsofaffectioncollection.com",
  "sub": "did:web:objectsofaffectioncollection.com:object:OBJECT_ID",
  "vc": {
    "@context": ["https://www.w3.org/ns/credentials/v2"],
    "id": "urn:credential:OBJECT_ID:…",
    "type": ["VerifiableCredential", "MaterialIntegrityCredential"],
    "issuer": "did:web:objectsofaffectioncollection.com",
    "validFrom": "2027-01-15T08:00:00Z",
    "credentialSubject": {
      "id": "did:web:objectsofaffectioncollection.com:object:OBJECT_ID",
      "materialIntegrity": { /* retail, make cost, spectacle multiple, material, provenance */ },
      "recordHash": "…",
      "anchor": { "status": "submitted", "merkleRoot": "…" },
      "methodologyRef": "https://objectsofaffectioncollection.com/colophon/methodology"
    }
  }
}   // JOSE header: { "alg": "EdDSA", "typ": "vc+jwt", "kid": "did:web:…#key-1" }
The issuer DID document (served at /.well-known/did.json) 
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:web:objectsofaffectioncollection.com",
  "verificationMethod": [{
    "id": "did:web:objectsofaffectioncollection.com#key-1",
    "type": "JsonWebKey2020",
    "controller": "did:web:objectsofaffectioncollection.com",
    "publicKeyJwk": { "kty": "OKP", "crv": "Ed25519", "alg": "EdDSA", "use": "sig", "x": "…" }
  }],
  "assertionMethod": ["did:web:objectsofaffectioncollection.com#key-1"],
  "authentication": ["did:web:objectsofaffectioncollection.com#key-1"]
}
The DPP-aligned passport export (GET /passport/{id}/dpp.json) 
{
  "schema": "dpp-aligned/groundwork-0.2",
  "note": "DPP-ALIGNED groundwork, not the final official Digital Product Passport schema.",
  "productIdentity": { "did": "…", "gs1DigitalLink": "…", "objectId": "…", "name": "…" },
  "dataCarrier": { "carrierType": "gs1-digital-link", "uri": "…" },
  "economicOperator": { "role": "accountability-data-provider", "identifier": "did:web:…" },
  "materialComposition": { "estimated": true, "primaryMaterial": "…" },
  "provenance": "…",
  "accountabilityCredential": { "type": "MaterialIntegrityCredential", "recordHash": "…", "resolve": "…" },
  "authenticityAttestation": { "ref": null, "controlledBy": null }
}

Verify one yourself

How anyone can check a Colophon credential.

No account, no SDK, no permission. Four steps with standard tooling.

  1. Resolve the issuer identity did:web:objectsofaffectioncollection.com to its DID document at /.well-known/did.json.
  2. Read the Ed25519 public key from verificationMethod[0].publicKeyJwk (the OKP x value).
  3. Fetch any object's passport at /passport/{object_id} and take its vc_jwt.
  4. Verify the VC-JWT's EdDSA signature against that public key. If it verifies, the record is ours and unaltered. If a single figure was changed, it will not.
Live self-check Checking…

This page asks our own /standards/conformance endpoint to issue a credential, verify it against the published DID document, and audit both, right now.

    An open reference implementation

    A reference the standards can be read through.

    The most durable position an institution can hold is to be the working example others check their understanding against. Colophon implements these specifications in the open, serves a live conformance report, and lets anyone verify a credential without trusting us. As the DID, Verifiable Credential, and Digital Product Passport standards settle, this is the reference they can be read through.

    Fence. This page reports conformance, meaning our records follow the named specifications. It is not a certification of any product, brand, or claim, and not a statement of full or final Digital Product Passport compliance. Colophon supplies an independently verifiable accountability record. Authenticity is a separate attestation a brand controls. Nothing here is minted, tokenized, or transferable.

    Build on the record with the Trust API