Target exists
A cloud, platform, domain, repository, API, agent, model, dataset or service identifier exists.
ECZ-ID SPECIFICATION
Cloud & Platform Binding Specification
This specification defines how ECZ-ID may represent supported relationships between an ECZ-ID and external cloud, platform, repository, domain, API, agent, model, dataset, MCP or service identifiers.
Provider identity remains provider-controlled. ECZ-ID adds a neutral accountability route that can help humans, agents, platforms and policy systems understand which ECZ-ID stands behind a digital surface.
Cloud accounts
Domains
Repositories
APIs
Agents
MCP servers
Models
Datasets
Core boundary: Websites explain. TrustOps operates. ECZ-ID Core controls state. Resolver verifies public proof where available. Developer Gateway documents implementation routes.
REFERENCE ROUTE
The binding route in one view.
A cloud or platform binding should be understandable as a route: an external identifier exists, setup is prepared, ECZ-ID Core controls state, and Resolver shows public-safe proof where available.
Setup starts
The customer follows a supported setup route through TrustOps.
Evidence is prepared
Supported challenge, DNS, .well-known, manifest, hash or manual proof material is prepared.
Core decides
ECZ-ID Core controls whether binding state can advance, degrade, expire, suspend or revoke.
Resolver projects
Resolver shows only public-safe proof fields where a projection is available.
Reviewer decides
Buyers, agents, auditors, insurers, platforms and policy systems apply their own rules.
SCOPE
What this specification covers.
External identifiers
Cloud accounts, tenants, domains, repositories, packages, APIs, applications, agents, MCP servers, models, datasets and platform profiles may be binding targets where a supported route exists.
ECZ-ID relationship
A supported target may be associated with an ECZ-ID identity route through controlled setup, evidence preparation, state handling and lifecycle review.
Public projection
Resolver may show public-safe cloud or platform binding posture only where ECZ-ID Core has published suitable proof fields for public review.
BINDING TARGETS
Digital surfaces that may need a clearer accountability route.
Cloud accounts and tenants
Cloud account, tenant, organisation, workspace or provider-level identifiers where a supported setup route exists.
Domains and web routes
Domains, DNS records, public backlinks and .well-known files used for route alignment and re-checkability.
Repositories and packages
Repository, package, release, provenance and software-supply-chain surfaces where operator routing matters.
APIs and tool surfaces
API endpoints, OpenAPI metadata, tools and public machine-readable interfaces where accountable operation matters.
Agents and MCP servers
Agent, tool, MCP server and automation surfaces where machines may need a route to accountable operation.
Models and datasets
Model, dataset, AI infrastructure and service surfaces where operator and evidence routing can support review.
PROVIDER ROUTE STATUS
Provider wording follows the route state.
Provider names identify where external identifiers exist. They do not imply provider endorsement, certification, affiliation, access rights or approval.
A provider route should only be described at the level actually supported by ECZ-ID evidence and setup capability.
RESOLVER PROJECTION
Resolver shows public proof fields, not private platform data.
Resolver may show
- Parent ECZ-ID and public-safe binding identifiers.
- Binding state, route state and target class.
- Masked identifiers and fingerprint hashes.
- Public-safe timestamps, TTL and re-check guidance.
- Current-state summaries where available.
- LedgerCore receipt references where public-safe.
- Machine-readable JSON for public re-check routes.
Resolver must not show
- Secrets, credentials, tokens, OAuth grants or cloud keys.
- Raw tenant IDs, account IDs, ARNs or private provider payloads.
- Private documents, raw telemetry, source code or operational logs.
- Payment status presented as proof of control.
- Provider approval, certification, endorsement or access-right claims.
- Safety, compliance, insurance or business-quality guarantees.
EVIDENCE AND SECURITY
Deterministic state. Durable evidence protection.
ECZ-ID binding state is controlled by ECZ-ID Core. Evidence-grade artifacts may use quantum-safe or hybrid signature approaches where required so long-lived proof material remains more resilient over time.
Quantum computation does not decide identity, authority, binding state or Resolver truth. Current public proof remains controlled by backend state and checked through Resolver where available.
RELIANCE INTERPRETATION
How to read a cloud or platform binding.
Binding route
A binding provides a structured route from an external identifier to an ECZ-ID accountability record.
Current state
Resolver should be used to check the current public state where a public proof route is available.
Review decision
Buyers, agents, insurers, auditors, platforms and counterparties remain responsible for applying their own review policies.
Interpretation limit
A binding does not replace provider login, account permissions, access control, billing ownership or provider identity systems.
REFERENCE PATH
Use the correct surface for the correct task.
Use .com for public explanation, TrustOps for acquisition and setup, Resolver for current public proof where available, and Developer Gateway for schemas and implementation guidance.