Skip to content
ECZ-IDDevelopers

ECZ-ID · Reciprocal Trust Infrastructure for the Machine Economy

PLUGIN PASSPORT · OPERATIONS · 04/04Public customer resource

ECZ-ID Plugin Passport Operations, Lifecycle and Troubleshooting Guide

Operate plugin/extension identity safely over time as publisher, store, repository/package, version and evidence context changes.

Download PDF(PDF, 188 KB)

Release 2026.10 · 16 October 2026

Plugin Passport documents
In this document
  1. Confirm the canonical plugin/extension before changing anything
  2. Control privately; prove publicly
  3. Update context without fragmenting identity
  4. Keep bounded plugin context current
  5. Change relationships carefully
  6. Make material plugin lifecycle changes visible
  7. Freshness belongs in operations
  8. One plugin/extension object, one canonical identity where supported
  9. Recover control without duplicating the plugin estate
  10. Diagnose by layer
  11. Send enough context - never secrets
  12. The recurring operational rhythm

About this document

Primary reader
Developer-platform administrator, software supply chain operations, security operations, estate owner.
Secondary reader
Support engineers, developers, plugin version managers and governance teams.
When to read this
The Plugin Passport exists and you need to operate, update, recover or troubleshoot it safely.
Release
2026.10 · 16 October 2026
What you will know after reading
You can preserve canonical identity, update distribution and host context, re-check Resolver proof, avoid duplicates and escalate failures without leaking secrets.
What this document does not establish
Operational changes do not automatically imply a new plugin/extension identity; identity continuity must follow the actual plugin/extension/integration component boundary.

NextUse the Technical Reference when you need machine consumer semantics or integration detail.

FIRST OPERATIONAL CHECK

Confirm the canonical plugin/extension before changing anything

Start every maintenance or troubleshooting action by identifying the intended Plugin ECZ-ID and its current organisation/Parent/publisher context.

  1. Step 1: IDENTIFY

    Confirm Plugin ECZ-ID and Passport family.

  2. Step 2: INSPECT

    Check Dashboard relationship, state, store/repository/package/host/version bindings and evidence.

  3. Step 3: RESOLVE

    Open the same ECZ-ID in Resolver and compare public proof.

  4. Step 4: SCOPE THE CHANGE

    Decide whether you are changing context or the plugin/extension object itself.

OPERATING LAW Preserve the canonical identity when the intended plugin/extension object remains the same; update context rather than minting a duplicate.

DASHBOARD VERSUS RESOLVER

Control privately; prove publicly

Use Dashboard for authenticated permitted actions and Resolver for public independent re-check.

  • DASHBOARD

    Authenticated customer control: inspect/manage permitted organisation relationship, bindings, evidence, state and lifecycle actions.

  • RESOLVER

    Public, read-only proof surface for counterparties and automation.

DO NOT CONFUSE Do not attempt to mutate public proof through Resolver; do not expose private customer/control data merely because Resolver is public.

  • AFTER A CHANGE

    Use Resolver to confirm the intended public result.

  • BEFORE A HIGH-CONSEQUENCE PLUGIN ADOPTION OR UPGRADE DECISION

    Re-resolve if freshness matters.

CHANGING STORE, REPOSITORY/PACKAGE OR DISTRIBUTION BINDINGS

Update context without fragmenting identity

Plugin-distribution changes are normal. Treat store, repository/package, host/platform, provider and version references as mutable supported context.

  • TYPICAL CHANGES

    • store/repository migration or rename
    • store listing / package namespace migration
    • host/platform or documentation change
    • marketplace/store or package-provider move
    • version / channel binding update

  • OPERATOR SEQUENCE

    • confirm canonical Plugin ECZ-ID
    • update supported binding/relationship
    • refresh evidence/state if needed
    • re-resolve and verify public result

DO NOT MINT BY DEFAULT A new repository, store listing, package coordinate, host/platform ID, provider project ID or package/store URL is not by itself a reason to create a new Plugin Passport.

  • PRESERVE IDENTITY WHEN

    The same intended plugin/extension/integration component persists.

  • RECONSIDER IDENTITY WHEN

    The plugin/extension object itself has genuinely changed.

VERSION, PERMISSIONS AND EVIDENCE REVIEW

Keep bounded plugin context current

Where supported, version context and evidence should be reviewed when distribution or publisher context changes or when the evidence itself becomes stale.

  • REVIEW TRIGGERS

    • new major/minor version
    • store/repository/package migration
    • publisher/maintainer change
    • store, package, host or docs move
    • evidence expiry or replacement

  • REVIEW QUESTIONS

    • is this still the intended plugin/extension?
    • do store/package/host/version bindings match current distribution?
    • is evidence still in scope/fresh?
    • did publisher/organisation responsibility or lifecycle state change?

DO NOT CLAIM SAFETY OR PERMISSION WITHOUT EVIDENCE Store, package, version, permission and capability context can be useful, but it does not establish safety, malware-free status, package integrity, review approval or execution permission unless supported evidence and local policy explicitly establish them.

  • REFRESH

    Update supported evidence/state through the canonical control path.

  • VERIFY

    Resolve again and inspect what counterparties can now observe.

PUBLISHER, MAINTAINER AND RESPONSIBILITY CHANGES

Change relationships carefully

Plugins/extensions can move between publishers, maintainers, organisations or product teams. Preserve identity where the same plugin/extension persists, while updating supported relationship/state.

  • BEFORE CHANGING

    Confirm the intended Plugin ECZ-ID and current Parent/organisation/publisher context.

  • AFTER CHANGING

    Verify new relationship, current state and evidence in Resolver.

RESPONSIBILITY BOUNDARY A publisher/maintainer change can coexist with one persistent Plugin identity where the object remains the same. A successor or fork should not inherit identity merely because it replaces the original.

  • AUDIT HABIT

    Record material publisher/distribution changes and re-check proof.

  • SECURITY HABIT

    Re-evaluate package/signature verification, store credentials, permission review, host approvals and execution policy separately from Passport identity.

LIFECYCLE STATES

Make material plugin lifecycle changes visible

Operational truth is useful when counterparties can tell that a plugin/extension is current, deprecated, suspended, withdrawn or archived according to supported canonical state.

  • CURRENT

    The published record represents the intended current plugin/extension/integration component context.

  • DEPRECATED

    Use supported state/evidence to communicate deprecation where available.

  • SUSPENDED / WITHDRAWN

    Temporary or permanent withdrawal should not be hidden behind stale “current” assumptions.

  • ARCHIVED / RETIRED

    Retain identity continuity where appropriate while making lifecycle status explicit.

CONSUMER EXPECTATION Counterparties should re-resolve rather than assuming an old publisher, store/package, host/version or lifecycle state remains current.

RESOLVER RE-CHECK POLICY

Freshness belongs in operations

Use re-resolution whenever publisher/organisation responsibility, store/repository/package bindings, version/capability context, evidence or lifecycle state can change faster than your cached decision.

RESOLVER RE-CHECK

Turn a presented Plugin ECZ-ID into a bounded decision input

Resolve the current public record, inspect only what is present, and fail safely when required proof is missing.

  • Consumer

    receives or discovers a Plugin ECZ-ID

  • then

    ECZ-ID Resolver

    public · read-only · re-checkable GET /api/p/{ecz_id}.json

  • Identity + family

    Is this the expected plugin/extension?

  • Responsibility

    Who claims publication/responsibility?

  • Bindings

    Store / repository / package / host refs

  • State

    Lifecycle / version context

  • Evidence

    What source, scope and freshness?

  • Boundary

    What is actually supported for this decision?

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

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

  • RE-CHECK AFTER

    Version change · store/repository/package migration · publisher change · evidence refresh · lifecycle change.

  • RE-CHECK BEFORE

    Consequential plugin adoption/upgrade decisions where stale identity/context would matter.

CACHE RULE Cache only according to use case. Re-resolve when freshness policy requires current proof.

DUPLICATE PREVENTION

One plugin/extension object, one canonical identity where supported

Duplicates create ambiguity for developers, security teams, counterparties and audit trails.

  • COMMON DUPLICATE TRIGGER

    A repository or store migration, namespace change, package-provider move, AWS subscription or sign-in issue is mistaken for a need to mint another identity.

  • CORRECT RESPONSE

    Identify the intended plugin/extension, recover or reuse the canonical account/Parent/Passport where supported, then update bindings/state instead.

DUPLICATE CHECK Before new issuance, resolve or search the known ECZ-ID and determine whether the existing record represents the same intended plugin/extension/integration component.

  • SAME PLUGIN/EXTENSION

    Preserve identity; update distribution and host context.

  • FORK/SUCCESSOR/DIFFERENT PLUGIN

    Issue a distinct Passport when the object boundary genuinely differs.

ACCOUNT RECOVERY AND CUSTOMER ACCESS

Recover control without duplicating the plugin estate

A sign-in or recovery problem is not evidence that the Plugin Passport should be reissued.

  • ACCOUNT PROBLEM

    Recover supported account access and confirm the organisation/Parent context.

  • PASSPORT PROBLEM

    Investigate issuance/reuse only if the canonical plugin/extension identity itself is missing or incorrect.

RECOVERY LAW Restore access to the canonical estate first. Do not create replacement accounts, Parents or Passports merely to work around a sign-in failure.

  • AFTER RECOVERY

    Confirm Dashboard shows the intended Plugin Passport.

  • THEN VERIFY

    Resolve the same ECZ-ID publicly and confirm the record remains consistent.

COMMON FAILURES

Diagnose by layer

Separate acquisition/account/control problems from proof/binding/freshness and plugin-security/runtime problems.

  • WRONG PLUGIN / ECZ-ID

    Confirm object boundary and identifier before changing anything.

  • BINDING STALE

    Update the supported store/repository/plugin/version binding; do not mint by default.

  • PROVENANCE/EVIDENCE MISSING

    Treat as absent unless supported evidence exists; do not infer signature/package/build integrity.

  • RESOLVER NOT FOUND

    Check identifier and acquisition/issuance state; distinguish from network/client failure.

  • STATE/EVIDENCE STALE

    Refresh through the canonical control path, then re-resolve.

  • PLUGIN SECURITY / HOST-POLICY FAILURE

    Diagnose signature/package verification, permission review, vulnerability, store/package/signature verification or host/runtime policy issues separately.

ESCALATE WITH LAYER CONTEXT Tell support whether the failure is acquisition, account access, Passport issuance/reuse, Dashboard control, Resolver proof, binding/state or plugin-security/runtime.

SUPPORT ESCALATION

Send enough context - never secrets

Good support context shortens diagnosis while preserving security.

  • INCLUDE

    • ECZ-ID / Passport ID if available
    • AWS account context if relevant
    • failed stage
    • visible error
    • occurrence time
    • expected vs observed behaviour

  • NEVER INCLUDE

    • passwords
    • store or package-registry access tokens
    • AWS Marketplace registration tokens
    • private signing keys / certificates
    • other credentials or secrets

SUPPORT support@ecocitizenz.com

If the issue affects a consequential production plugin adoption or upgrade decision, apply your own plugin-security, change-control and runtime policies while the identity/proof issue is investigated.

ONE-MINUTE OPERATOR RUNBOOK

The recurring operational rhythm

Use this as the minimum repeatable check for a Plugin Passport in service.

  1. Step 1: Identify

    Confirm the canonical Plugin ECZ-ID.

  2. Step 2: Inspect

    Check Dashboard responsibility, bindings, state and evidence.

  3. Step 3: Update

    Apply permitted contextual changes; preserve identity when the plugin/extension is the same.

  4. Step 4: Resolve

    Re-check public proof after material change.

  5. Step 5: Challenge

    If required proof is missing/stale/mismatched, do not silently infer.

  6. Step 6: Escalate

    Send bounded context to support - never secrets.

OPERATING OUTCOME Counterparties can continue to resolve one durable plugin/extension identity while supported store listing, repository/package, publisher, host, version, state and evidence context changes.

Download and support

This page is the HTML edition of ECZ-ID Plugin Passport Operations Lifecycle and Troubleshooting Guide, release 2026.10. The PDF is the designed offline copy.

Download PDF(PDF, 188 KB)

Support: support@ecocitizenz.com

Permanent route: https://developers.ecocitizenz.com/passports/plugin/operations/