One identity for your plugin, in every store it is listed in.

• One identity, wherever it appears

  One Plugin Passport is one logical plugin, extension, action or store app your organisation publishes. Every place your plugin appears becomes a binding to its one ECZ-ID.

• Proof anyone can re-check

  A public Resolver record and its JSON, for people and software, with no account and no key — and a badge that routes to it.

• Free, and nothing to migrate

  £0, permanently. It sits beside the identity systems you already run and stays outside the execution path.

1. 01

   Take the Passport

   Start in TrustOps with one sign-in. Your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created, and your plugin gets its free Plugin Passport — one ECZ-ID that does not change.

2. 02

   Bind an asset

   Name an asset your plugin is known by — for example the documentation site you publish for the plugin. Binding never creates a second identity. Each binding records where it was learned.

3. 03

   Choose and prepare a proof method

   Choose the live proof method that fits the asset: Domain /.well-known file or DNS TXT record. Places no live method reaches are marked Planned. Your ECZ-ID console gives you the exact value to publish for that method.

4. 04

   Complete the proof and review

   Publish it on the asset you control, then tell ECZ-ID the proof is in place. The binding is reviewed before anything about it is published as verified.

5. 05

   ECZ-ID verification, then the Resolver

   ECZ-ID checks the published proof and records the outcome with the time it checked. The Resolver then shows the binding with its proof method, its Last verified date and its Re-check due date — to anyone, with no account and no API key.

6. 06

   Operate — re-check before reliance

   Keep the proof in place. A binding is verified as of a time, not indefinitely: ECZ-ID does not renew a bound binding, and after its method's freshness window a new binding is the fresh proof — re-check before reliance. Publish the ECZ-ID where people and machines already look. Strengthen only if it is useful: Parent verification, monitoring, evidence and authority are optional, and none is needed to hold a Passport.

• A publisher growing from a handful of plugins to a portfolio listed in several stores.Plugin operating productPlugin Publisher & Permission Integrity →
• Getting an editor extension onto an enterprise allow-list.Plugin specialist kitECZ-ID Marketplace App Security & Enterprise Approval Kit →
• A publisher growing from one plugin to a production portfolio.ScaleAEC — Active Entity Capacity →
• Mapping every plugin you publish and the permissions each one requests.Professional servicesExpert help →
• Noticing that a bound public surface no longer matches the identity.Current state · MonitorPulseGuard →
• Showing an enterprise reviewer when a binding or publisher change was recorded.Evidence · HistoryLedgerCore →
• Answering who operates your plugin and what it connects to, in one view.Relationships · DependenciesECZ-ID Graph Intelligence →
• An enterprise following the plugins it relies on.Change · Follow · NotificationECZ-ID Watch →
• Authorising what one of your plugins may do and checking each proposed action against it, under one plan.Authority · Intent and runtime decisionsECZ-ID Intent + Intent Control →

1. DECLARED

   ECZ-ID Business Passport — Declared — FREE

   Free · created with your first Passport

   Self-declared organisation identity, published with the date it was declared. Not independently verified.

   Suits: Holding every free Passport in every family, publishing records, adding bindings and being resolved by anyone.

   Never presented as verified.

2. VERIFIED

   ECZ-ID Business Passport — Verified

   Optional · arranged through TrustOps

   Independent verification of the organisation behind your Passports. Paying opens ECZ-ID's checks; the record shows VERIFIED only after they pass.

   Suits: Production use, and reviewers who need to know who is answering for what they approve.

   Never verifies a child Passport's subject, and never changes an ECZ-ID.

3. ASSURED

   ECZ-ID Business Passport — Assured

   Optional · arranged through TrustOps

   The higher-assurance organisation posture. Paying opens ECZ-ID's checks; the record shows ASSURED only after they pass.

   Suits: Larger or more sensitive estates, and enterprise procurement.

   Never verifies a child Passport's subject, and never changes an ECZ-ID.

Native where you operate. ECZ-ID where you interoperate.Keep the identities your platforms need. Add the identity everyone else can resolve.

• Extension and app marketplaces

  What it does: Distribute plugins, extensions and apps, under their own review processes.

  What ECZ-ID adds beside it: One identity across every store, with each listing recorded as a binding rather than a second identity.

• Source repositories

  What it does: Host the code a library, plugin or server is built from.

  What ECZ-ID adds beside it: A binding from the repository to the enduring subject, recorded with where it was learned.

• OAuth 2.x and OpenID Connect

  What it does: Delegate authorisation and authenticate a principal for a session.

  What ECZ-ID adds beside it: A durable public record of the subject and its operator that outlives any token and needs none to read.

• Model Context Protocol (MCP)

  What it does: Connects AI applications to tools and data through a defined client–server protocol.

  What ECZ-ID adds beside it: A resolvable identity for the agent and, separately, for each MCP server it uses — each with a named operator.

Platforms, standards and providers are named to show where ECZ-ID sits alongside them. Naming them implies no endorsement by, or partnership with, their owners.

ECZ-ID complements your frameworks, protocols, OAuth, cloud IAM and workload identity. It replaces none of them and stays outside the execution path.

Read the interoperability boundaries in full→