Skip to content
ECZ-IDSDK

Included free · One identity, many places · ECZ-ID SDK

Bindings

Every place your SDK or library appears, tied to one identity.

A binding records a public place where your SDK or library already appears — a package registry listing or the canonical source repository — 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 SDK or library 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

  • SDK publishers present in more than one registry or language ecosystem.
  • Teams that rename, move or re-publish a library without changing what it is.
  • Reviewers who need to know that two registry entries are one library.

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 SDK Passports: Domain /.well-known file or DNS TXT record.
  • Bindings shown on the public record, with consent.
Bindings on one record
Identity
ECZ-XX-XXXXXX::SDK_PASSPORT-XXXXXX
Verified binding
your published documentation
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 package registry listing — 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.

  1. Passport — Your SDK or library holds one free SDK Passport, issued through TrustOps and written by ECZ-ID Core.

  2. Bind asset — Name an asset your SDK or library is known by — for example your published documentation. Binding never creates a second identity.

  3. 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.

  4. Prepare — Your ECZ-ID console gives you the exact value to publish for that method.

  5. Complete proof — Publish it on the asset you control, then tell ECZ-ID the proof is in place.

  6. Review — The binding is reviewed before anything about it is published as verified.

  7. ECZ-ID verification — ECZ-ID checks the published proof and records the outcome with the time it checked.

  8. Resolver — The public record shows the binding, its proof method, when it was last verified and when a re-check is due.

  9. 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

  • Recording the npm, PyPI, Maven Central and NuGet channels of one client library against one ECZ-ID, as declared bindings.
  • Recording the canonical source repository against the same identity, so a moved or renamed repository is still one SDK.
  • Recording an OCI reference where the SDK is also distributed as an image.
  • Verifying the documentation site on a domain you control through a DNS TXT record or a /.well-known file.

Price

Included free, with every Passport.

£0. It is part of the free SDK Passport — permanent, not a trial, and no card is required.

After you take it

  1. TrustOps acquires

    Take the free Passport in TrustOps; your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created.

  2. Dashboard operates

    Operate it in the Dashboard: publish, bind and copy your proof links.

  3. 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 package registry listing — recorded as a declared binding; its connector is Planned.
  • The canonical source repository — recorded as a declared binding; its connector is Planned.
  • An OCI registry reference — recorded as a declared binding; its connector is Planned.
  • Your published documentation — Domain /.well-known file or DNS TXT record.
Does each registry channel need its own Passport?
No. Releases, versions and registry channels of that library are not separate Passports. A different library is a second Passport.
Does a binding prove I control the registry account?
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 package registry channel is recorded as a declared binding today; the connector for it is Planned.
Which places can a live proof method reach today?
A package registry listing — recorded as a declared binding; its connector is Planned. The canonical source repository — recorded as a declared binding; its connector is Planned. An OCI registry reference — recorded as a declared binding; its connector is Planned. Your published documentation — 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.