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=1Canonical 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.
| State | Meaning | Treat as proof? |
|---|---|---|
| CLAIMED | Operator claimed the domain in TrustOps. No evidence observed yet. | No |
| CHALLENGE_ISSUED | TrustOps issued a challenge value. Awaiting publication. | No |
| OBSERVED | Backend observed at least one signal but verification is incomplete. | No |
| BOUND | Backend observed matching control evidence at the stated time. | Yes |
| EXPIRED | Previous proof has lapsed. | No |
| MISMATCH | Observed value does not match the issued challenge or canonical record. | No |
| REVOKED | Operator 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.
