ECZ-ID Plugin Passport Overview and Customer Guide

• WHAT STAYS DURABLE

  The Plugin ECZ-ID for the intended plugin/extension/integration component where continuity is appropriate.

• WHAT CAN CHANGE

  Store listing, repository/package, publisher metadata, host/platform relationship, version, declared capabilities/permissions where supported and evidence.

• RESOLVER

  Public, read-only proof a human or machine can independently re-check.

• DASHBOARD

  Authenticated customer control for permitted lifecycle and estate actions.

• WITHOUT A PERSISTENT IDENTITY

  Teams may rely on a plugin name, repository URL, store listing, package coordinate or host-platform reference - each tied to a particular distribution or host context and potentially mutable.

• WITH PLUGIN PASSPORT

  The plugin can present a stable ECZ-ID with bounded publisher/organisation responsibility, current state, bindings and evidence that counterparties can resolve again.

• RESPONSIBILITY CAN ANSWER

  Which organisation claims responsibility for publishing or operating this Plugin identity?

• RESPONSIBILITY DOES NOT MEAN

  Every version, capability, permission, security property or third-party claim has been independently verified.

• PUBLISHER CHANGES

  A maintainer or publisher relationship can change while the canonical plugin/extension identity remains stable where appropriate.

• PARENT CONTEXT

  Links the Plugin Passport to the responsible organisation/Parent where present.

• EVIDENCE

  Supports bounded claims according to source, scope and freshness.

• RE-CHECK

  Resolve again when publisher/organisation responsibility matters to the decision.

• REPOSITORY

  Source repository or project reference where supported.

• MARKETPLACE/STORE OR PACKAGE SURFACE

  Store listing / package namespace / package coordinate.

• VERSION

  Plugin/extension version reference where supported.

• HOST / PLATFORM

  Host/platform relationship where supported.

• PERMISSIONS / CAPABILITIES

  Declared permissions/capabilities where supported and evidenced.

• EVIDENCE LINK

  Reference that supports a bounded claim about the plugin/extension identity.

• IDENTITY PERSISTS

  The ECZ-ID can remain stable across supported store, package, host/platform and version changes when the underlying plugin/extension object remains the same.

• CONTEXT CHANGES

  Published version/lifecycle state, bindings and evidence should be re-checked when freshness matters.

• GOOD CONSUMER BEHAVIOUR

  Read source, scope and freshness; re-resolve before consequential adoption or upgrade decisions.

• UNSAFE SHORTCUT

  Assuming an old version, host, store binding or publisher context is still current because the ECZ-ID itself is unchanged.

• IDENTITY

  Which plugin/extension object is this?

• RESPONSIBILITY

  Who claims publication/responsibility?

• LOCAL POLICY

  Is this plugin/version permitted in this environment?

• SECURITY CONTROLS

  Are permissions, signing, vulnerability, host-policy and runtime requirements satisfied?

• REPOSITORY MIGRATION

  Preserve plugin/extension identity when source hosting moves.

• MARKETPLACE/STORE OR PACKAGE MIGRATION

  Keep the same ECZ-ID while supported store/package coordinates change.

• VERSION VERIFICATION

  Connect a stable plugin/extension identity to current version context.

• ENTERPRISE EXTENSION REVIEW

  Give architecture/security teams a re-checkable identity anchor for a plugin/extension.

• MACHINE CONSUMPTION

  Allow automation to resolve bounded plugin/extension identity/context before plugin adoption or upgrade decisions.

• CROSS-STORE / CROSS-PLATFORM DISTRIBUTION

  Treat store, host and provider-native plugin IDs as bindings rather than the authority root.

• BEFORE

  Consumers know the Plugin by ECZ-ID plus store, repository, package and version bindings.

• AFTER

  The Plugin ECZ-ID remains stable; supported store/host/package bindings and evidence are updated and Resolver reflects the current record.

• CONSUMER ACTION

  Re-resolve before adopting the new distribution location or version.

• SECURITY ACTION

  Validate package signatures, vulnerabilities, host/organisation approval and local approval independently.

• STRONG FIT

  Plugins/extensions distributed across stores, repositories/packages, versions or providers where durable identity matters.

• SECURITY FIT

  Teams that need a stable object identity before applying separate plugin/extension supply-chain controls.

• DEVELOPER FIT

  Tooling that needs a machine-resolvable plugin/extension identity independent of one package coordinate.

• LOWER-VALUE FIT

  Single-use or ephemeral plugin/extension artifacts where persistent cross-context identity brings little benefit.

• If required proof is present and fresh → evaluate local plugin/host policy / proceed

• If absent, stale or mismatched → challenge, deny, pin or re-resolve

MACHINE-READABLE ROUTE

GET https://api.ecocitizenz.com/api/p/{ecz_id}.json

• IF REQUIRED PROOF IS PRESENT

  Evaluate the decision using the returned state, bindings and evidence plus your local plugin/host policy.

• IF REQUIRED PROOF IS ABSENT

  Treat it as not established; challenge, pin, deny or seek additional evidence rather than infer.

• OBJECT

  Plugin / extension / integration component.

• PERSISTENT IDENTITY

  One canonical ECZ-ID can survive store, repository/package and version changes where object continuity holds.

• RESPONSIBILITY

  Organisation/Parent and publisher context where present.

• BINDINGS

  Store, repository/package, docs, version and provider references where supported.

• EVIDENCE + STATE

  Bounded, point-in-time context; source, scope and freshness matter.

• BOUNDARY

  Not plugin safety, vulnerability-free status, package/build attestation, host approval or execution permission.