Specifications
Passport Specification
An ECZ-ID Passport describes a bounded operating surface under a stable parent ECZ-ID. It attaches scope, lifecycle state, authority boundaries and Resolver-verifiable public proof to the parent identity. It does not create a second identity root.
INFORMATIVE DRAFT Informative specification
Canonical URL: https://www.ecocitizenz.org/pages/passport-specification
Passport rule Link to section: Passport rule
Scoped state remains subordinate to parent identity. A Passport represents one bounded operating surface, such as an agent or an API, and it inherits the public identity context of its parent ECZ-ID.
A Passport can change state — issued, active, suspended, degraded, expired, mismatched, revoked or unresolved — without changing the parent ECZ-ID.
Child structure Link to section: Child structure
| Part | Role | Illustrative example |
|---|---|---|
| Parent ECZ-ID | The stable identity spine for the organisation or entity. | ECZ-GB-A93K7Q |
| Passport code | The controlled code for the Passport’s scope, such as the code for an API Passport. The current public families are listed under Current public Passport families. | API |
| Instance suffix | Separates one Passport instance from another under the same parent, without becoming a second identity root. | 2Q7X9B |
| Child instance form | Parent, Passport code and instance suffix together. | ECZ-GB-A93K7Q::API-2Q7X9B |
| Resolver path | The public route for current state and safe public proof for that instance. | /p/ECZ-GB-A93K7Q/API/2Q7X9B |
What a Passport defines Link to section: What a Passport defines
- Scope
- What the Passport covers, what it does not cover, and which operating surface it represents.
- Authority boundary
- Which backend-controlled authority conditions allow the Passport state to exist, change, degrade, be suspended or be revoked.
- Lifecycle state
- Whether the Passport is issued, active, suspended, degraded, expired, mismatched, revoked or unresolved.
- Public proof
- What Resolver may safely project for people, agents, platforms, auditors, insurers and automated relying systems.
How a Passport becomes public reference Link to section: How a Passport becomes public reference
| Step | What happens |
|---|---|
| 1. Parent exists | A stable parent ECZ-ID identifies the organisation, operator or eligible subject. |
| 2. Scope is selected | A controlled Passport type defines the bounded operating surface. |
| 3. Instance is created | A scoped instance separates one Passport object from another under the same parent. |
| 4. State is controlled | The ECZ-ID backend controls issuance, activation, suspension, expiry and revocation. |
| 5. Resolver projects | Resolver shows public-safe proof fields where a projection is available. |
| 6. Reviewer decides | People, agents, platforms and policy systems apply their own review rules. |
Passport boundary Link to section: Passport boundary
A Passport provides
- A scoped, Resolver-verifiable accountability surface.
- A public way to distinguish parent identity from operating-object state.
- Lifecycle posture that can change without losing the parent ECZ-ID.
- Machine-readable reference material for integration, procurement, audit and review.
A Passport does not
- Create a second ECZ-ID identity root.
- Prove business quality, reputation, performance, safety or commercial suitability.
- Replace regulators, auditors, insurers, courts or institutional decision-makers.
- Make a website, badge, listing, directory entry or copied document authoritative.
- Allow public pages, agents or third-party interfaces to write ECZ-ID state.
Public-safe proof Link to section: Public-safe proof
Where a projection exists, public-safe Passport proof can include the Passport type and instance reference, the parent ECZ-ID, the current lifecycle state, effective dates and re-check guidance, public-safe receipt references and machine-readable Resolver output.
Current public Passport families Link to section: Current public Passport families
The current core public Passport family set comprises seven families:
- Agent Passport
- MCP Passport
- Plugin Passport
- API Passport
- IoT Passport
- SDK Passport
- Service & Workload Passport
Each family follows the Passport model set out in this specification:
- Scoped beneath a Parent ECZ-ID
- Whatever its family, a Passport is scoped beneath a stable Parent ECZ-ID. A family names a Passport scope; it is not a separate identity root.
- Provider identifiers are bindings
- Provider-native identifiers, such as an agent or MCP server ID, a package or plugin name, an API endpoint, a device serial or a cloud workload identity, are bindings to the ECZ-ID. They do not replace it as the identity root. See the Cloud & Platform Binding Specification.
- Identity is not blanket authority
- Holding a Passport in any family identifies an accountable operating surface. It does not confer blanket authority: authority, delegation and intent remain separate, scoped stages of the accountability chain. See the Authority Model.
- Current proof is re-checked in Resolver
- A family name, badge, listing or copied page is not proof. The current state of any Passport is re-checked through Resolver.
- Where action and detail live
- Acquisition, activation and lifecycle action belong in TrustOps. Implementation guidance belongs in Developer Gateway. Family-specific explanation belongs on the dedicated Passport sites listed under Passport discovery.
Passport discovery Link to section: Passport discovery
Passport-specific discovery and acquisition happen on dedicated Passport sites, not on ecocitizenz.org. They explain a Passport and route to acquisition; they do not replace these specifications or Resolver.
- Agents agents.ecocitizenz.com
- MCP servers mcp.ecocitizenz.com
- APIs apis.ecocitizenz.com
- IoT and connected products iot.ecocitizenz.com
- Plugins plugins.ecocitizenz.com
- SDKs sdk.ecocitizenz.com
- Services and workloads workloads.ecocitizenz.com
Where to go next Link to section: Where to go next
Verify — Resolver
- Why leave this site
- This page explains rules. It cannot show whether a particular ECZ-ID, Passport or binding is current.
- Where you go
- Resolver (resolver.ecocitizenz.org)
- Authority there
- Current public proof: a read-only projection of backend-controlled state.
- What happens next
- Open the ECZ-ID or Passport record and re-check its current public status before you rely on it.
Acquire, activate, manage or pay — TrustOps
- Why leave this site
- You want to acquire, activate, manage or pay for an ECZ-ID or Passport.
- Where you go
- TrustOps (trustops.ecocitizenz.com)
- Authority there
- Acquisition, payment, entitlement, activation and lifecycle operations.
- What happens next
- Start or manage the operational acquisition and lifecycle flow. Payment or activation is not itself proof.
Implement — Developer Gateway
- Why leave this site
- You need schemas, SDKs, route indexes or integration patterns rather than governance text.
- Where you go
- Developer Gateway (developers.ecocitizenz.com)
- Authority there
- Implementation, interoperability, SDK and schema guidance. It is not live proof.
- What happens next
- Use the implementation guides and reference material. Live proof still comes from Resolver.
Read together Link to section: Read together
Revision history Link to section: Revision history
| Date | Version | Status | Change summary |
|---|---|---|---|
| No controlled revision of this document has been published. Earlier versions of this page on the Shopify-hosted site were not issued under a documentary authority record, so no history is backfilled. | |||
Recommended citation Link to section: Recommended citation
EcoCitizenz Ltd, Passport Specification, DRAFT, https://www.ecocitizenz.org/pages/passport-specification.
Fields that do not yet exist for this document, such as a document ID or version, are omitted rather than invented.