EcoCitizenZ
HomeBinding RegistryDomain binding
Binding type · Domain

Domain binding

Bind an ECZ-ID to a domain you control. TrustOps issues the challenge. Backend/Core observes it. Resolver projects BOUND only after backend verification.

When to use domain binding

  • You need to prove that a business controls a specific domain.
  • A counterparty needs machine-checkable evidence before signing, paying, or integrating.
  • A platform requires a verifiable operator domain before listing.

Prerequisites

  • An active parent ECZ-ID issued through TrustOps.
  • DNS access for the target domain.
  • A TrustOps-issued challenge value bound to your ECZ-ID.

Setup sequence

  • TrustOps issues a backend-controlled challenge value for the target domain.
  • You publish the challenge as a DNS TXT record and as a canonical well-known JSON file.
  • Backend/Core observes both signals from its own infrastructure.
  • Resolver projects BOUND only after Backend/Core has verified the control evidence.

DNS TXT record

Publish a TXT record at the _eczid subdomain. The challenge value is issued by TrustOps and bound to your ECZ-ID.

DNS TXT example
Record Type: TXT
Host: _eczid
Value:
ecz-id=ECZ-GB-XXXXXX; challenge=<backend-issued-challenge>; v=1

Canonical well-known path

The canonical well-known location is /.well-known/ecz-id.json. The legacy alias /.well-known/eczid.json may be supported where already deployed, but /.well-known/ecz-id.json is canonical for new deployments.

/.well-known/ecz-id.json
{
  "ecz_id": "ECZ-GB-XXXXXX",
  "binding_type": "domain",
  "issuer": "EcoCitizenz",
  "version": "1",
  "challenge": "<backend-issued-challenge>",
  "resolver": "https://resolver.ecocitizenz.org",
  "issued_at": "<timestamp>"
}

Setup artifact, not proof

This file is a setup artifact. It is not proof until Backend/Core observes it, validates it, and Resolver projects the BOUND state.

Verification states

Resolver may report any of the following states for a domain binding. Only BOUND is operational proof.

StateMeaningTreat as proof?
CLAIMEDOperator claimed the domain in TrustOps. No evidence observed yet.No
CHALLENGE_ISSUEDTrustOps issued a challenge value. Awaiting publication.No
OBSERVEDBackend observed at least one signal but verification is incomplete.No
BOUNDBackend observed matching control evidence at the stated time.Yes
EXPIREDPrevious proof has lapsed.No
MISMATCHObserved value does not match the issued challenge or canonical record.No
REVOKEDOperator or registry revoked the binding.No

Failure handling

  • DNS not found — verify the _eczid TXT record is published and propagated; re-trigger observation in TrustOps.
  • Challenge mismatch — re-issue from TrustOps and republish; old challenges never become valid retroactively.
  • Stale challenge — challenges expire; the binding returns to CHALLENGE_ISSUED until a new value is observed.
  • Domain moved — issue a new binding for the new domain; the old binding moves to REVOKED.

Privacy posture

  • A domain may appear publicly in Resolver only after the binding reaches BOUND.
  • Challenge values and temporary setup tokens are never standalone proof and are never published as such.
  • Resolver does not expose internal infrastructure details.
ECZ-ID keeps setup, verification state, and public proof separated by design. TrustOps handles setup. Resolver remains the public proof surface. Re-check before reliance.