Skip to content
ECZ-IDSDK
Free Passport: Get a FREE SDK Passport

ECZ-ID SDK Passport™

Give your SDK an identity that travels with every release and distribution channel.

For publishers of SDKs, libraries and packages on npm, PyPI, Maven, NuGet and other registries. Connect publisher identity, package bindings, releases, provenance and current public proof across registries and downstream software — under one public ECZ-ID anyone can re-check on the Resolver.

Get a FREE SDK PassportVerify an ECZ-IDBuild and integrate(opens in a new tab — developers.ecocitizenz.com)

£0 · No card required · Permanent, not a trial.

Everything included with one FREE SDK Passport

Identity
ECZ-XX-XXXXXX::SDK_PASSPORT-XXXXXX
Operator
Your organisation's ECZ-ID Business Passport — Declared — FREE, created if you do not have one
Public proof
Resolver page + machine-readable JSON, open to anyone
Share
Live website badge + QR code + share link
Connections
Basic bindings + Digital Entity Graph participation
Operate
Lifecycle/current state on demand + claim/recovery + essential LedgerCore evidence
Price
£0 — no card required — permanent, not a trial

The website badge is the same live-proof pattern EcoCitizenz uses in every site footer: click it to reach current Resolver proof. DECLARED information is self-declared; re-check the live record before relying on it.

Free SDK Passport

What your free SDK Passport establishes.

One SDK Passport is one logical SDK, library or package your organisation publishes. Releases, versions and registry channels of that library are not separate Passports.

Free · Permanent · No card

The ECZ-ID launch model

Every organisation starts with one ECZ-ID Business Passport — Declared — FREE. Each of the seven family Passports — Agent, MCP, Plugin, API, IoT, SDK and Service & Workload — is free, and is taken in TrustOps once TrustOps publishes that family's door as open.

ECZ-ID Business Passport — Declared — FREEParent · created with your first family Passport

Other free starts

  • Free WatchFollow up to three ECZ-IDs on this device and see what changed, with no account and no email.Use Free Watch
  • Free Trust CheckCheck a public URL: we read its public signals and match them to the free Passport families by fixed rules. Advisory; nothing is created.Run the free check

Included, at £0

  • A persistent ECZ-ID for the SDK or library.
  • Your organisation on the record as its operator. Its ECZ-ID Business Passport — Declared — FREE is created if you do not already have one. About the Parent
  • A public Resolver record anyone can open, and the same record as machine-readable JSON. About the Resolver
  • A badge, a QR code and a share link. About badges and QR
  • Basic bindings to the public places where your SDK or library already appears. About bindings
  • Lifecycle and current public state, evaluated on demand. About PulseGuard
  • Claim and recovery.
  • Basic participation in the Digital Entity Graph. About the Graph
  • Essential lifecycle evidence, kept in LedgerCore. About LedgerCore
  • Publish Kit for your package metadata and README badge.
  • Manage from your ECZ-ID account.

Publishing the record is your decision. Nothing becomes public until you consent, and you can withdraw publication later.

One SDK, one Passport

For example, your client library keeps one Passport across npm, PyPI and its other registry channels, release after release.

A new version, release, registry channel or package artefact is not a new Passport.

What the record never blurs

DECLARED ≠ VERIFIED
A DECLARED record states what your organisation says about itself, with the date it said it. It is not the outcome of an independent check.
Passport ≠ Binding
The Passport identifies the SDK or library. A binding records a public place where it already appears. Adding a binding never creates a second identity.
Binding ≠ Authority
A binding shows that a relationship has been declared. It does not grant, prove or imply authority to act.
Parent verification ≠ SDK verification
A VERIFIED or ASSURED Parent verifies your organisation. It does not verify the SDK or library.
Get a FREE SDK PassportRead everything included

Why, and how it works

From Passport to verified binding.

Why your SDK or library needs an ECZ-ID, and exactly what happens between taking the Passport and relying on a verified binding.

  • One identity across every release and registry

    One SDK Passport is one logical SDK, library or package your organisation publishes. Registry channels, the source repository and every release are recorded against it — never a second identity.

  • Publisher continuity anyone can re-check

    A public Resolver record and its JSON name the organisation that publishes the library — for developers, reviewers and build tools, with no account and no key.

  • Free, and nothing in the build path

    £0, permanently. There is no client SDK to install: the identifier travels as metadata the package already has, outside the execution path.

One identity from the publisher to every application that depends on it.

  1. Publisher

    Your organisation's ECZ-ID Business Passport — Declared — FREE, created with your first family Passport and strengthened to VERIFIED or ASSURED only if you choose.

    Enduring · public · accountable

  2. publishes

    SDK Passport

    One enduring ECZ-ID for the logical SDK or library, whatever it is called in each ecosystem.

    Enduring · public · accountable

  3. built from

    Source repository

    Recorded as a declared binding: host, owner and repository, never a branch or a commit. The repository connector is Planned.

    Moves with every release and channel

  4. released as

    Builds and releases

    Each version is history under the same SDK, with its build provenance where you supply it — never a new Passport.

    Moves with every release and channel

  5. distributed through

    Package registries

    npm, PyPI, Maven Central, NuGet and others. Each channel is recorded as a declared binding, without a version; the registry connectors that would verify them are Planned.

    Moves with every release and channel

  6. depended on by

    Consuming applications

    Downstream software reaches the publisher record from the package it already uses — a README badge, a manifest field or a machine lookup.

    Moves with every release and channel

  7. re-checked on

    Resolver

    The current public record, for people and software, which itself says it is not a verdict and must be re-checked before reliance.

    Enduring · public · accountable

  8. extended with

    SBOM · evidence · Watch

    Composition, append-only evidence and change awareness attach to the same identity, when you choose to add them.

    Moves with every release and channel

A Passport records who publishes the SDK and where it is distributed. It does not prove that a build was secure. Registry, repository and OCI bindings are declared today; their connectors are Planned. A binding on a domain you control is verified through a live proof method, as of its Last verified time.

  1. 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 SDK or library gets its free SDK Passport — one ECZ-ID that does not change.

  2. Bind an asset

    Name an asset your SDK or library is known by — for example your published documentation. Binding never creates a second identity. Each binding records where it was learned.

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

The binding law

  1. Passport
  2. Bind asset
  3. Proof method
  4. Prepare
  5. Complete proof
  6. Review
  7. ECZ-ID verification
  8. Resolver
  9. Operate

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.

Use cases

What SDK teams use ECZ-ID for.

Real situations, each served by one product of the ECZ-ID SDK domain. Every product starts from the same free SDK Passport; none of them changes what it proves.

Operate this Passport

Operate your SDK estate.

When one free SDK Passport becomes many, these are the products TrustOps lists for the SDK family. Each is optional and separate, and none changes what a Passport proves.

Universal platform

Five universal capabilities. One job each.

Scale → Monitor → Evidence → Understand relationships → Know when something changes.Five ECZ-ID capabilities sit behind every Passport family. All are optional, none changes what a Passport proves, and each is arranged through TrustOps.

One AEC: An SDK or package you actively manage in production, with live bindings and current state. A free Passport exists and resolves whether or not you use any AEC.

IoT devices are counted separately, in IoT Fleet Capacity, and never consume AEC.

Authority & evidence, your estate plan and expert help

What a Passport may do and how a proposed action is evaluated, where receipts are kept, how the estate is operated and who can help — each optional, none of them changing what a Passport proves.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.

Parent assurance

Strengthen the organisation, not the identity.

Every SDK Passport hangs from your organisation's Parent, the ECZ-ID Business Passport. DECLARED is free and enough to start; VERIFIED and ASSURED strengthen confidence in who is answering for your SDK or library — never the SDK or library itself.

  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.

Compare the Parent tiersConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)

Solutions

Solve the review, procurement and supply-chain problem above the identity.

Each solution uses the same free SDK identity foundation. None is a certification, a score or an approval.

Where it applies — DCI — Digital Counterparty Infrastructure. Make a digital service easier for people and machines to identify, inspect and re-check. DCI is identity and evidence infrastructure, not a counterparty risk score or approval.

DCI details

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. All solutions

Flagship digital product

ECZ-ID SDK Release Provenance & Customer Assurance Kit

Make SDK release provenance and dependency evidence easier for customers to review.

Before an enterprise approves an SDK, its reviewers ask who publishes it, whether the release they are pulling came from that publisher, what it depends on and how releases are controlled. Publishers answer from registry screenshots and scattered CI logs, differently for every customer — and the answer is stale by the next release.

What you receive

  • Publisher and package identity evidence
  • Release provenance prompts
  • Dependency evidence structure
  • Customer assurance artefacts

Boundary: The kit documents provenance and evidence; it does not guarantee package security. An ECZ-ID identifies the publisher and the SDK; it does not prove a build was secure, reproducible or free of vulnerabilities.

See the full productConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)
The SDK release assurance pack
Publisher
Your Business Passport and the SDK's ECZ-ID
Distribution
Every registry channel, recorded against the one identity as a declared binding
Release
vX.Y.Z — source repository, pipeline and attestation references, where supplied
Composition
The SBOM for that release, from your own tooling
Gaps
Open questions a customer's reviewer will raise about the release, stated plainly
Boundary
Documents provenance — does not prove the build was secure

Illustrative structure with placeholder values. The pack is assembled from your evidence; the Resolver remains the live proof.

Relevant bundles

When the problem spans more than one kind of entity.

Bundles connect the specialist products across a real workflow. Each identity stays distinct; a bundle never merges them.

How the estate fits together

TrustOps acquires. Dashboard operates. Resolver proves.

ECZ-ID Core writes the canonical identity, state and evidence. This website explains and hands off; it never issues, edits or stores an identity.

  1. TrustOps acquires

    Owns acquisition, payment and entitlement. Every free door and every purchase happens there, and nowhere else.

    Open TrustOps(opens in a new tab — trustops.ecocitizenz.com)About TrustOps

  2. Dashboard operates

    The signed-in estate console where you manage Passports, bindings, capacity and the capabilities you hold.

    Sign in — manage from your ECZ-ID account(opens in a new tab — trustops.ecocitizenz.com)About Dashboard

  3. Resolver proves

    Public, read-only proof. Anyone can open the current record and its JSON with no account, and re-check it before relying on it.

    Verify an ECZ-IDAbout Resolver

Developer Gateway documents and integrates. Schemas, client guidance and install routes for resolving ECZ-IDs from your own code.

Open the Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Live proof

Don't take our word for it. Resolve us.

EcoCitizenz Ltd runs this site and holds its own ECZ-ID. Everything below is read from the public record, by anyone, with no account and no key — including the parts that are empty.

ECZ-ID

active

EcoCitizenz

ECZ-GB-RBS1NW

Operated by
ECOCITIZENZ LTD
Organisation tier
VERIFIED
Bound representations
None published
Public relationships
None published

The parent organisation's identity is verified. This machine is not.

Evidence available

  • Not revoked
  • Anchor recorded · not publicly retrievable
  • No live PulseGuard monitor
  • No receipts in 30 days
Resolve(opens in a new tab — resolver.ecocitizenz.org)JSON(opens in a new tab — api.ecocitizenz.com)View Graph
Last read from the public record 2026-10-14. The Resolver is the authority. Re-check before reliance.

Check it yourself

The same record answers for humans and machines. One is a page, the other is JSON with no authentication in front of it.

curl -s https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json | jq .

What each field means is documented on the Developer Gateway: Resolver projection(opens in a new tab — developers.ecocitizenz.com)

What it does not prove

That this company is safe to deal with, that its software is correct, or that anyone has audited it. A record establishes who an entity is and who operates it. Everything else is your decision, and you should re-check before you rely on it.

Open the record(opens in a new tab — resolver.ecocitizenz.org)Resolve any ECZ-IDGet the same badge for your organisation

Interoperability

Works alongside what you already run.

An SDK Passport complements package registries, the repositories behind them and the pipelines that publish to them. The registry distributes your library; the Passport publishes who stands behind it.

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

Related family Passports

  • Package registries — npm, PyPI, Maven, NuGet and others

    What it does: Distribute the versions of your library.

    What ECZ-ID adds beside it: One publisher-linked identity for the library across every registry it is published to.

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

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

Add an enduring identity and proof layer. Replace nothing.

Keep your pipelines, attestations and SBOMs. Add the publisher identity everyone downstream can resolve.

  • CI/CD pipelines

    What it does: Build, test and publish each release — in GitHub Actions, GitLab CI or whichever system you run.

    What ECZ-ID adds beside it: The organisation that publishes through that pipeline, named on one public record every release can be read against. ECZ-ID neither reads nor verifies the pipeline.

  • Trusted publishing

    What it does: Lets a CI workflow publish to a registry with short-lived, OIDC-based credentials instead of a stored token.

    What ECZ-ID adds beside it: The organisation behind that workflow and package, named on a public record that outlives any one token exchange.

  • Artifact provenance and signing

    What it does: Describe where and how an artifact was built, and sign it — for example SLSA-style provenance or Sigstore signatures.

    What ECZ-ID adds beside it: An enduring publisher identity those attestations can be read against, release after release. ECZ-ID verifies neither the build nor the signature.

  • SBOM tooling

    What it does: Describe the components inside a release — in CycloneDX, SPDX or the format your tooling emits.

    What ECZ-ID adds beside it: The publisher and the enduring product identity the SBOM describes, beside it. Never a claim that the components are safe.

  • Developer ecosystems

    What it does: READMEs, documentation sites and package manifests — where developers meet the SDK.

    What ECZ-ID adds beside it: A live badge and a manifest-field link back to the current Resolver record. Metadata only; never in the execution path.

Names identify kinds of tooling you may already run. No row implies a partnership, an endorsement or a certified integration, and ECZ-ID neither verifies nor changes their output. There is no ECZ-ID client SDK or package to install.

Enterprise and questions

Larger estates, and the questions people ask first.

Enterprise, partners and expert help

Estate-wide capacity, procurement terms, partner arrangements and fixed-scope expert engagements are agreed directly rather than bought online. The SDK Passport itself stays free at any scale.

EnterpriseTalk to us
What does a free SDK Passport cost?
£0. It is permanent, not a trial, and no card is required. You pay only if you later add scale, assurance or specialist products.
What does one SDK Passport identify?
One SDK Passport is one logical SDK, library or package your organisation publishes. Releases, versions and registry channels of that library are not separate Passports.
Who can check the record for my SDK or library?
Anyone. Once you consent to publication, the Resolver serves the record as a page and as JSON, with no account and no key.
What would I ever pay for?
Capacity to operate more entities (AEC), a stronger organisation tier (Parent VERIFIED or ASSURED), monitoring, evidence, relationship intelligence, change awareness, business solutions and specialist digital products. All are optional.
Does the SDK Passport verify the SDK or library?
A DECLARED record states what your organisation says. A VERIFIED or ASSURED Parent verifies your organisation, not the SDK or library. A binding completed through a live proof method shows control of the bound asset as of when it was last verified; it certifies nothing about the SDK or library itself.

Every question, answered

Start with the identity. Everything else is optional.

£0 · No card required · Permanent, not a trial.

Get a FREE SDK PassportVerify an ECZ-ID