ECZ-ID · Reciprocal Trust Infrastructure for the Machine Economy
ECZ-ID Passport and Parent Identity Model
How organisation identity, Parent ECZ-IDs and specialised child Passports relate without creating duplicate identity or competing authority roots.
Release 2026.10 · 16 October 2026
Shared Foundation documents
In this document
- Parent identity is the organisation-level anchor
- A Passport identifies the specialised object
- Parent and child Passports form a relationship, not a flattened identity
- Responsibility and assurance must be read as bounded signals
- Persistent identity should survive ordinary infrastructure change
- Lifecycle changes update context; they do not automatically mint a new identity
- Duplicate prevention is an identity-quality requirement
- Three examples of the model in practice
- FAQ and safe interpretation boundaries
About this document
- Primary reader
- Organisation administrators, enterprise architects, identity teams, developers and security teams
- Secondary reader
- Platform operations, governance, support and technical evaluators
- When to read this
- You understand ECZ-ID generally and need to design how an organisation, Parent ECZ-ID and specialised Passport objects fit together.
- Release
- 2026.10 · 16 October 2026
- What you will know after reading
- You can model one Parent with specialised Passports, understand persistence and lifecycle, interpret responsibility and assurance conservatively, and avoid duplicate identity.
- What this document does not establish
- A Parent relationship does not grant blanket authority, prove every declaration, or automatically make each child Passport independently verified.
PARENT CONCEPT
Parent identity is the organisation-level anchor
A Parent ECZ-ID represents the organisation or responsible identity context to which specialised machine/software Passports can relate.
What the Parent does
Provides a persistent organisation-level identity context that child Passports can reference. It helps counterparties understand which organisation claims responsibility for the represented object.
What the Parent does not do
It does not turn every child object into the same identity, grant every child the same authority, or make all child evidence inherit the Parent’s assurance automatically.
One organisation can have one Parent context while many specialised Passports identify distinct machine/software objects.
PASSPORT CONCEPT
A Passport identifies the specialised object
Each child Passport represents a specific object class while retaining the same ECZ-ID trust grammar.
Agent Passport
AI / software agent
MCP Passport
MCP server / tool surface
API Passport
API / service interface
IoT Passport
Device / IoT object
SDK Passport
SDK / package / release family
Plugin Passport
Plugin / extension / integration
Service & Workload Passport
Service / workload / runtime identity
Free identity primitives: all seven Passport families are free. Paid ECZ-ID capabilities, where relevant, are optional extensions rather than prerequisites for basic Passport identity.
PARENT + PASSPORT MODEL
Parent and child Passports form a relationship, not a flattened identity
The Parent explains organisation context; each Passport remains the identity of its own object.
ORGANISATION CONTEXT
Parent ECZ-ID
Agent
AI / software agent
MCP
Server / tool surface
API
Service interface
IoT
Device / IoT object
SDK
Package / release family
Plugin
Extension / integration
Service & Workload
Service / workload / runtime
Interpretation: the Parent relationship communicates responsibility context. It does not collapse the seven objects into one record or imply that the Parent directly authorises every child action.
RESPONSIBILITY & ASSURANCE
Responsibility and assurance must be read as bounded signals
Where a record displays responsibility or an assurance state, interpret the state actually shown and the supporting evidence actually present.
DECLARED
A declaration is presented. Do not silently treat a declaration as independently verified.
VERIFIED
Where this state is displayed, read the verified status and its evidence as scoped to what was actually verified.
ASSURED
Where this state is displayed, interpret it as the current assurance state in context - not as universal certification of all child objects or behaviour.
Boundary: responsibility answers “who claims responsibility?” Assurance answers a different question. Authority answers another. Keep them separate.
IDENTITY PERSISTENCE
Persistent identity should survive ordinary infrastructure change
The canonical identity should normally remain stable while supported bindings, state and evidence evolve around it.
Step 1: Create / reuse
Use the canonical Parent and Passport if the legitimate identity already exists.
Step 2: Bind
Attach supported provider IDs, endpoints, repositories, manifests, package or runtime references.
Step 3: Change
Update supported bindings/state when infrastructure or ownership context changes.
Step 4: Re-check
Counterparties continue resolving the same ECZ-ID and see current published context.
Stable
ECZ-ID for the same legitimate object; canonical relationship history where supported.
Changeable
Endpoints, versions, provider references, runtime context, state, evidence and supported bindings.
LIFECYCLE
Lifecycle changes update context; they do not automatically mint a new identity
The exact lifecycle vocabulary depends on the canonical implementation. Customers should read the state actually published and avoid inferring undocumented states.
Typical change triggers
Endpoint/provider migration, release changes, operator changes, relationship changes, evidence updates, suspension/revocation/degradation signals where the implementation exposes them.
Identity decision
Ask whether the underlying object is still the same legitimate identity. If yes, update its context rather than creating a duplicate simply because an integration changed.
Freshness: lifecycle state is point-in-time. Re-resolve before decisions that depend on current state.
DUPLICATE PREVENTION
Duplicate prevention is an identity-quality requirement
A new provider subscription, endpoint, runtime, marketplace listing or sign-in event is not by itself a reason to create another canonical identity.
Before creating
Search for the existing organisation/Parent and relevant Passport.
When acquiring again
Reuse supported existing account/Parent/Passport paths where appropriate.
When uncertain
Challenge the identity relationship rather than silently creating parallel records.
The target outcome is one canonical identity per legitimate object - not one identity per provider, subscription, endpoint or click.
EXAMPLES
Three examples of the model in practice
These examples show how Parent identity and child Passports remain distinct while expressing organisation responsibility.
Agent + API
An organisation Parent is related to an Agent Passport and an API Passport. The agent may bind to the API, but identity and action authority are evaluated separately.
SDK + Plugin
A publisher Parent can be related to SDK and Plugin Passports. Repository, registry and store references can change while the child ECZ-IDs remain stable if the underlying objects remain the same.
Workload migration
A Service & Workload Passport can keep its ECZ-ID while provider/runtime references are updated. Provider-native workload IDs remain bindings, not authority roots.
QUICK REFERENCE
FAQ and safe interpretation boundaries
Use this final page when modelling your estate or deciding whether a new Parent/Passport is actually required.
| Question | Answer |
|---|---|
| Does every child need a different Parent? | No. Specialised child Passports can relate to the relevant organisation Parent where appropriate. |
| Does a Parent relationship grant authority? | No. Authority/delegation is action-specific and must be evaluated separately where required. |
| Should a provider migration create a new ECZ-ID? | Not merely because the provider changed. Update supported bindings if the underlying legitimate object is the same. |
| Does VERIFIED/ASSURED propagate every claim to every child? | No. Interpret the displayed state and evidence within its actual scope. |
| What if I suspect a duplicate? | Stop creating additional identities and use the supported account/identity reconciliation or support path. |
Next: Use the Resolver guide to verify a record, or the relevant Passport family guide to understand the specialised object.
Download and support
This page is the HTML edition of Passport and Parent Identity Model, release 2026.10. The PDF is the designed offline copy.
Permanent route: https://developers.ecocitizenz.com/guides/passport-parent-identity-model/