Included free · One identity, many places · ECZ-ID Plugin
Bindings
Every place your plugin appears, tied to one identity.
A binding records a public place where your plugin already appears — a VS Code Marketplace or Open VSX entry or an agent-platform plugin listing — against its one ECZ-ID. Where a live proof method reaches the place, completing the proof shows the binding as verified, with when it was last verified. Adding a binding never creates a second identity.
- Type
- Included free
- Price
- £0 — included with every free Passport
- Acquired and paid in
- TrustOps
- Operated in · proved by
- Dashboard · Resolver
The problem
Why it matters.
The same plugin shows up in several places under several accounts. Readers cannot tell that they are the same thing, or who stands behind each one.
Built for
- Plugin publishers present in more than one marketplace or registry.
- Teams that rename, move or re-list a plugin without changing what it is.
- Reviewers who need to know that two listings are one plugin.
What changes
- One identity across every place it appears.
- Every bound place pointing back to the same public record.
- A clear record of where each binding was learned, which are verified, and as of when.
What you receive
Concrete deliverables, not a vague trust score.
- Basic bindings with every free Passport.
- The source each binding was learned from.
- The live proof methods for Plugin Passports: Domain /.well-known file or DNS TXT record.
- Bindings shown on the public record, with consent.
- Identity
- ECZ-XX-XXXXXX::
PLUGIN_PASSPORT-XXXXXX - Verified binding
- the documentation site you publish for the plugin
- Proof method
- Domain /.well-known file or DNS TXT record — whichever was completed
- Last verified
- YYYY-MM-DD
- Re-check due
- YYYY-MM-DD
- Declared binding
- a VS Code Marketplace or Open VSX entry — connector Planned; no Last verified date
- Learned from
- The source of each binding, recorded
Illustrative structure with placeholder values. A declared binding shows no Last verified date; a verified one shows when it was last verified and when a re-check is due.
How it works
A short path from need to something usable.
Passport — Your plugin holds one free Plugin Passport, issued through TrustOps and written by ECZ-ID Core.
Bind 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.
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.
Prepare — Your ECZ-ID console gives you the exact value to publish for that method.
Complete proof — Publish it on the asset you control, then tell ECZ-ID the proof is in place.
Review — The binding is reviewed before anything about it is published as verified.
ECZ-ID verification — ECZ-ID checks the published proof and records the outcome with the time it checked.
Resolver — The public record shows the binding, its proof method, when it was last verified and when a re-check is due.
Operate — 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.
How it relates to your Passport
Bindings are part of the free Passport. AEC counts the entities you actively manage with live bindings; PulseGuard can evaluate the current state of bound surfaces; ECZ-ID Watch tells followers when they change.
Use cases
- Binding a VS Code Marketplace or Open VSX entry to its one ECZ-ID.
- Binding an agent-platform plugin listing to its one ECZ-ID.
- Binding a store app listing to its one ECZ-ID.
- Binding the repository the plugin is built from to its one ECZ-ID.
- Binding the documentation site you publish for the plugin to its one ECZ-ID.
Price
Included free, with every Passport.
£0. It is part of the free Plugin Passport — permanent, not a trial, and no card is required.
After you take it
TrustOps acquires
Take the free Passport in TrustOps; your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created.
Dashboard operates
Operate it in the Dashboard: publish, bind and copy your proof links.
Resolver proves
Anyone resolves the current record on the Resolver.
Privacy, security and evidence
What is collected, published and kept.
- Each binding records where it was learned.
- A verified binding shows its proof method and when it was last verified; a declared one is shown as declared.
- Publication of bindings follows the same consent as the record.
Boundaries
The claims stop here.
- Passport ≠ Binding. A binding records an asset; it is never a second identity.
- Binding ≠ Authority. A binding does not grant, prove or imply authority to act.
- Binding ≠ Certification. A completed proof shows control of the named asset when it was checked. It is not a certification, does not grant authority, and says nothing about safety or quality.
- A binding is verified as of its Last verified time, and the record shows its Freshness. ECZ-ID does not renew a bound binding: once its proof method's freshness window has passed, the result is history and a new binding is the fresh proof. Re-check before reliance.
- A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.
Integrations and questions
Works with what you already run.
- A VS Code Marketplace or Open VSX entry — recorded as a declared binding; its connector is Planned.
- An agent-platform plugin listing — recorded as a declared binding; its connector is Planned.
- A store app listing — recorded as a declared binding; its connector is Planned.
- The repository the plugin is built from — recorded as a declared binding; its connector is Planned.
- The documentation site you publish for the plugin — Domain /.well-known file or DNS TXT record.
- Does each marketplace listing need its own Passport?
- No. Releases, versions and individual store listings of that plugin are not separate Passports.
- Does a binding prove I control the listing?
- Only a binding completed through a live proof method shows control of that asset, and only as of its Last verified time. A declared binding records the relationship and where it was learned. Neither grants authority. A marketplace or store listing is recorded as a declared binding today; the connector for it is Planned.
- Which places can a live proof method reach today?
- A VS Code Marketplace or Open VSX entry — recorded as a declared binding; its connector is Planned. An agent-platform plugin listing — recorded as a declared binding; its connector is Planned. A store app listing — recorded as a declared binding; its connector is Planned. The repository the plugin is built from — recorded as a declared binding; its connector is Planned. The documentation site you publish for the plugin — Domain /.well-known file or DNS TXT record. A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.
Related
- Included free · Public proofResolverPublic, read-only proof of identity for your plugin, for anyone who asks.Read more
- Included free · RelationshipsDigital Entity GraphSee how your plugin relates to the entities around it.Read more
- ScaleAEC — Active Entity CapacityScale the estate you actively operate without turning capacity into identity.Read more
Start with a free Plugin Passport.
£0 · No card required · Permanent, not a trial.
