ECZ-ID · Reciprocal Trust Infrastructure for the Machine Economy
ECZ-ID Plugin Passport Technical Reference
Technical semantics for plugin/extension identity, publisher/organisation responsibility, bindings, version/lifecycle state, evidence, Resolver representation and integration.
Release 2026.10 · 16 October 2026
Plugin Passport documents
In this document
- What exactly does a Plugin Passport represent?
- The Plugin ECZ-ID at the centre of bounded context
- Responsibility is represented as context, not universal assurance
- How the persistent identity connects to a changing plugin/extension supply chain
- Separate persistent identity from mutable plugin and host context
- Evidence supports bounded claims - it is not magic provenance
- Identity is not permission to install or execute code
- Public proof and machine-readable resolution
- A safe integration pattern
- Keep the identity meaningful as distribution changes
- Store and host platforms are context, not canonical authority
- Treat absence and ambiguity explicitly
- Apply the model to real package-distribution patterns
- The external integration contract in one page
About this document
- Primary reader
- Developer, architect, security engineer, integration engineer.
- Secondary reader
- Platform engineers, automated-system designers, software supply chain teams and technical evaluators.
- When to read this
- You understand the product and need to integrate or interpret Plugin Passport proof precisely.
- Release
- 2026.10 · 16 October 2026
- What you will know after reading
- You can identify the canonical object, supported relationships/bindings, state/evidence semantics, machine route, lifecycle and safe failure behaviour.
- What this document does not establish
- This is not an internal schema dump and does not promise fields or evidence that the current canonical implementation does not expose.
NextRead the Operations Guide for lifecycle changes, stale context, duplicate prevention and troubleshooting.
CANONICAL OBJECT
What exactly does a Plugin Passport represent?
The canonical object is a plugin / extension / integration component - not the repository URL, store listing or package coordinate, version string, download URL or credential used to access it.
CANONICAL IDENTITY
Persistent ECZ-ID representing the intended plugin/extension object across supported context changes.
EXTERNAL REFERENCES
Store, repository/package, namespace, version, documentation and provider IDs are bindings/context.
OBJECT BOUNDARY A new plugin version does not automatically mean a new Plugin identity; a genuinely different plugin/extension/integration component should not inherit the same identity merely because it replaces the old one.
STABLE
ECZ-ID where object continuity holds.
MUTABLE
Bindings, version context, publisher relationship, state and evidence.
IDENTITY GRAPH
The Plugin ECZ-ID at the centre of bounded context
The graph should be read as relationships and evidence around a persistent identity - not as a universal trust score.
PLUGIN PASSPORT PROOF MODEL
What a Plugin Passport can prove and contextualise
A persistent plugin/extension identity with bounded publisher/organisation responsibility, store/repository/package and host/platform bindings, version/capability context and evidence that can be independently re-checked.
PERSISTENT
Plugin ECZ-ID
plugin / extension / integration identity
Organisation / Publisher
responsibility context where supported
Repository / Package
repository / source reference where present
Store / Package
marketplace listing / package coordinate
Version / Capabilities
version reference / declared capabilities
Provenance / Evidence
source · scope · freshness where supported
Current Published State
lifecycle · version operational context
Host / Platform
host/platform relation where supported
ECZ-ID Resolver
independent public re-check
Boundary: a Plugin Passport does not prove plugin safety, vulnerability-free status, package/build integrity or permission to install, enable or execute.
GRAPH READING LAW Each edge has its own scope. A repository binding does not prove publisher authority; publisher/organisation responsibility does not prove plugin safety; evidence does not become a blanket “trusted” verdict.
MACHINE CONSUMER
Inspect only fields/relationships relevant to the decision.
HUMAN REVIEWER
Read source, scope and freshness before drawing a conclusion.
PARENT, ORGANISATION AND PUBLISHER RELATION
Responsibility is represented as context, not universal assurance
Where present, a Parent/organisation relationship or publisher context links the Plugin object to the organisation claiming responsibility for it.
CAN ESTABLISH
The record publishes the shown organisation/Parent or publisher/organisation responsibility context.
CANNOT ESTABLISH BY ITSELF
That every version, capability, permission, dependency or third-party statement has been independently verified.
AUTHORITY NOTE Supported authority/delegation may be represented where present, but identity or publisher/organisation responsibility is not blanket authority for every host action, tool/API invocation or version decision.
USE RELATIONSHIP
As bounded accountability context.
USE EVIDENCE
To understand support, source and scope.
RE-CHECK
When publisher/organisation responsibility is material.
DO NOT INFER
Certification, plugin safety or version integrity beyond evidence.
BINDINGS
How the persistent identity connects to a changing plugin/extension supply chain
Bindings can associate the Plugin ECZ-ID with supported external surfaces and identifiers.
REPOSITORY
Source/repository reference.
STORE / PACKAGE
Marketplace/store listing or package coordinate/namespace where supported.
VERSION
Plugin/extension version reference where supported.
HOST / PLATFORM
Host/platform relationship or integration surface where supported.
PERMISSIONS / CAPABILITIES
Declared permissions/capabilities where supported and evidenced.
OTHER SUPPORTED BINDING
Additional store, repository/package, host or provider references represented by the canonical system.
SEMANTICS A binding says the ECZ-ID record is associated with the external surface according to current evidence/state. It does not make that surface the identity authority root.
VERSION, PERMISSIONS/CAPABILITIES AND CURRENT STATE
Separate persistent identity from mutable plugin and host context
Where supported, current state can carry point-in-time lifecycle and version family context while the Plugin ECZ-ID remains stable.
STATE MAY CHANGE
Version, declared permissions/capabilities where supported, host/platform relationship, deprecation/withdrawal context, publisher relationship, bindings and evidence may change over time.
IDENTITY MAY PERSIST
The same intended plugin/extension object can retain the ECZ-ID across those supported contextual changes.
FRESHNESS Do not cache a plugin trust conclusion indefinitely. Re-resolve when current version, publisher, host, permissions/capabilities or binding context matters.
CONSUMER PATTERN
Read current state and evidence before a consequential install, enable, upgrade or invocation decision.
BOUNDARY
Current state is not a guarantee of code behaviour, vulnerability status or future safety.
EVIDENCE AND PROVENANCE
Evidence supports bounded claims - it is not magic provenance
Evidence can support claims about plugin/extension identity, responsibility, bindings, version/capability context and other supported relationships according to source, scope and freshness.
REPOSITORY EVIDENCE
Can support association to a source repository where represented.
REGISTRY EVIDENCE
Can support association to a package-store listing or package coordinate.
VERSION EVIDENCE
Can support bounded version relationships where represented.
PUBLISHER EVIDENCE
Can support responsibility/publisher context where represented.
PROVENANCE BOUNDARY Do not infer signed-build provenance, reproducibility, artifact integrity, SBOM completeness or cryptographic attestation unless the specific evidence explicitly supports it.
AUTHORITY AND ADOPTION BOUNDARY
Identity is not permission to install or execute code
Some interactions require separate evidence/policy that a package may be adopted, upgraded, distributed or executed in a particular environment.
PRE-USE VERIFICATION
Verify identity and context before you adopt a plugin or extension
Use Passport proof as one input; keep package/signature verification, signature/package verification, permission review, vulnerability review and host/runt
Step 1: Obtain Plugin ECZ-ID
from store listing, docs, repository/package or publisher
Step 2: Resolve
confirm family/object and publisher context
Step 3: Inspect bindings
store, repository/package host + version refs
Step 4: Check freshness
state, evidence and current plugin context
Step 5: Evaluate local controls
permissions + signing / vulnerability + host policy
Step 6: Decide
allow, challenge, pin or deny
Step 7: Re-check
before consequential install or upgrade
Boundary: Plugin identity/proof does not replace plugin/package verification, vulnerability management, permissions review or host execution policy. If required proof is absent, stale or mismatched, challenge or deny rather than infer.
DECISION BOUNDARY Evaluate plugin/package signing/authentication, vulnerability status, host/organisation approval policy, approved versions, change control and runtime restrictions separately from Plugin identity.
PASSPORT CONTRIBUTION
Which package is this and what bounded publisher/distribution/host context is current?
LOCAL CONTROLS
Is this exact artifact/version permitted and safe enough for this environment?
RESOLVER REPRESENTATION
Public proof and machine-readable resolution
Resolver is the public, read-only proof surface. It is designed for independent re-check by humans and machines.
HUMAN USE
Inspect ECZ-ID, family/object, organisation/Parent/publisher context, current state, bindings and evidence where present.
MACHINE USE
GET https://api.ecocitizenz.com/api/p/{ecz_id}.json and evaluate only the returned fields relevant to policy.
READ-ONLY Resolver does not mutate the Plugin Passport. Changes flow through the authenticated/canonical control path and become visible when the public record is updated.
RE-CHECK
Use Resolver again when publisher, store/package, version or evidence freshness matters.
NOT FOUND / ABSENT
Treat required missing data as not established; do not fabricate a fallback plugin/extension identity.
MACHINE-CONSUMER CONTRACT
A safe integration pattern
Treat Resolver output as structured identity/proof context, not as an all-purpose “trust = true” signal.
Step 1: PARSE IDENTITY
Read the stable ECZ-ID and confirm Plugin Passport family/object.
Step 2: CHECK RESPONSIBILITY
Evaluate organisation/Parent/publisher context if policy requires it.
Step 3: CHECK BINDINGS
Compare store/repository/package/host/version references relevant to the plugin/extension.
Step 4: CHECK STATE/EVIDENCE
Evaluate required current state, evidence scope and freshness.
Step 5: APPLY LOCAL CONTROLS
Package/signature verification, vulnerability review, permissions, host/platform policy and execution controls remain separate.
Step 6: FAIL SAFELY
If required proof is missing, stale or mismatched, challenge/deny/pin/re-resolve.
NO UNIVERSAL SCORE Do not reduce the record to a single “trusted plugin” boolean unless your own policy defines and justifies that decision from specific fields/evidence.
LIFECYCLE AND VERSION FAMILY CONTINUITY
Keep the identity meaningful as distribution changes
A plugin/extension can move through publication, active maintenance, major versions, deprecation, store/repository/package migration, withdrawal and archival while retaining identity continuity where the object remains the same.
OPERATIONS LIFECYCLE
Operate one durable Plugin identity through change
Update supported distribution and host context and evidence without fragmenting the canonical plugin/extension identity.
Plugin ECZ-ID
stable plugin/extension identity
Confirm Plugin identity
start from the canonical Plugin ECZ-ID
Update bindings
store · repository/package host · version refs
Refresh evidence
source · scope freshness
Publish state
lifecycle · version operational context
Re-check Resolver
verify what counterparties see
OBJECT CONTINUITY Update supported bindings/state/evidence when distribution and host context changes. Mint a distinct identity when the plugin/extension object/version family boundary genuinely differs.
PRESERVE
Same intended plugin/extension object; context changes.
SEPARATE
Different plugin/extension object that replaces or forks the original.
FAILURE HANDLING
Treat absence and ambiguity explicitly
Safe integrations distinguish not-found, missing-evidence, stale-context, wrong-object and transport/client errors.
NOT FOUND
Confirm ECZ-ID and distinguish missing record from network/client failure.
WRONG FAMILY/OBJECT
Do not treat another Passport family or plugin/extension as equivalent.
BINDING MISMATCH
Challenge if store/repository/plugin/version reference does not match the intended package.
EVIDENCE ABSENT
Treat required provenance/context as not established.
STATE STALE
Re-resolve or require fresh evidence according to policy.
PLUGIN SECURITY / HOST-POLICY FAILURE
Signature/vulnerability/permissions/runtime failure remains a separate control outcome.
FAIL CLOSED WHEN REQUIRED If your decision requires a field/evidence and it is absent, stale or mismatched, do not infer it away.
WORKED INTEGRATION EXAMPLES
Apply the model to real package-distribution patterns
Examples show how the same persistent identity can support different operational contexts without claiming more than the record proves.
MARKETPLACE/STORE OR PACKAGE MIGRATION
Same Plugin ECZ-ID; supported store/package binding updates.
REPOSITORY MOVE
Same plugin/extension identity; repository/source binding changes.
MAJOR VERSION
Same version family identity where object continuity is intended; version context updates.
ENTERPRISE PLUGIN ADOPTION GATE
Resolve identity, publisher/bindings/state/evidence, then apply local signature/vulnerability/permissions policy.
SECONDARY STORE / MIRROR
A secondary store or package mirror is binding/context; canonical identity remains ECZ-ID.
PLUGIN SUCCESSOR / FORK
A genuinely different plugin/extension should receive its own identity even if it replaces the original in a product stack.
EXAMPLE LAW Examples illustrate the identity model; they do not promise every binding or evidence type is always present.
DEVELOPER QUICK REFERENCE
The external integration contract in one page
Use this page when implementing a verifier or integration around Plugin Passport proof.
OBJECT
Plugin / extension / integration component.
STABLE IDENTIFIER
ECZ-ID.
MACHINE ROUTE
GET https://api.ecocitizenz.com/api/p/{ecz_id}.json
KEY CONTEXT
Parent/publisher · state · store/repository/package/host/version bindings · evidence.
MUST NOT INFER
Code safety · vulnerability-free status · build provenance · host approval · install/execute authority.
FAILURE RULE
Required absent/stale/mismatched proof → challenge, deny, pin or re-resolve.
NEXT Read the Operations, Lifecycle and Troubleshooting Guide before implementing plugin-identity changes or production support workflows.
Download and support
This page is the HTML edition of ECZ-ID Plugin Passport Technical Reference, release 2026.10. The PDF is the designed offline copy.
Permanent route: https://developers.ecocitizenz.com/passports/plugin/technical-reference/