SDKs and libraries
Two different things are called an SDK. Only one of them exists yet.
The SDK Passport family is an identity for a library you publish. An ECZ-ID client library is something you would install and call. This page keeps them apart, and says plainly which one you cannot have today.
The integration route that works today needs no library at all.
Disambiguation
Which one did you come here for?
Meaning 1 — a Passport family
You publish a library, and want it to have an identity
The SDK Passport family gives one logical library or SDK a permanent ECZ-ID, published against the organisation that maintains it. The subject is your library. Consumers of it can resolve who stands behind the thing they are about to depend on.
FREE — like every ECZ-ID Passport family.
Meaning 2 — a client library
You want a library that talks to ECZ-ID from your code
An ECZ-ID client SDK for developers. There is not one. No package, no install command, no version, and nothing on this site that pretends otherwise.
Not published yet.
Meaning 1 — the Passport family
One SDK Passport is one logical SDK, library or package your organisation publishes, across every language and registry it ships to.
What one SDK Passport covers
One library, with a permanent identifier and the organisation that maintains it named on the record. Somebody deciding whether to take a dependency can resolve it without an account, and read who is behind it rather than inferring from a registry profile.
Registries, release channels and language bindings belong to the one library; none of them is a Passport of its own. Bindings, versions, replicas, endpoints and deployments never consume AEC and never become a second Passport. Identity is free. A Passport is never metered, and issuing one consults no entitlement.
Not a separate Passport
Versions and releases
Every release of the same library carries the same identity. An identifier that changed with the version number would be a version string, not an identity.
Registry channels
The same library published to several package registries is one subject with several distribution channels, not several libraries.
Language bindings of the same library
Bindings that expose one design in several languages stay one Passport. Two genuinely separate products, maintained separately, are two.
Mirrors and rebuilds
A mirror redistributes what you already published. It is a channel, and it does not create a new subject.
Where the family is documented
The SDK family is FREE, like every Passport family, and an SDK Passport sits under the same organisation — the same Parent — as any other Passport you hold. Your ECZ-ID does not change. Adding an adjacent identity never disturbs the one you already hold. The Developer Gateway is where the family is documented in full.
Developer Gateway(opens in a new tab — developers.ecocitizenz.com)
Facing a supply-chain review of the library?
Turn software composition and provenance into evidence a buyer can actually review. Every release of the library keeps its one identity, so composition evidence can follow it across versions. An SBOM describes composition and evidence; it is not a declaration that software is secure.
Adjacent Passports are suggested, never issued for you. If your agent also exposes an MCP server or an API, you choose whether to give those an identity too.
Meaning 2 — the client library
There is no ECZ-ID client SDK. Stated plainly, because the alternative is worse.
No package, no install command
There is no name to type, in any registry, for any language. This site names no library, publishes no import snippet and pins no version.
No SDK version and no protocol binding
Nothing here describes an A2A binding, a plugin or a framework adapter shipped by ECZ-ID. Where a technical detail is not published, this site omits it rather than approximating it.
If you find one, it is not ours
An install command for an ECZ-ID client library, from any source, is not something this programme has published. Treat it accordingly.
Status of an ECZ-ID client library: not published. Full integration reference, schemas and API documentation live on the Developer Gateway. This property gets you an identity and points you at the right place to wire it in.
What works today
The route that is live needs no library at all.
One file on a surface you already serve
/.well-known/ecz-agent.json
The agent declares its ECZ-ID at a well-known path on the deployment it already exposes. The Publish Kit issued with your Passport gives you the contents; you serve the file the way you serve any other static asset.
ECZ-ID stays outside the execution path. It does not broker your agent's calls, hold its credentials, or sit between it and the systems it uses.
Which makes the language question moot
A static file has no runtime, so there is nothing to port. The route is identical in every language below, and in the ones not listed.
TypeScript and JavaScript
Publish a static JSON file from the deployment you already run.
Python
Publish a static JSON file from the deployment you already run.
Go
Publish a static JSON file from the deployment you already run.
.NET
Publish a static JSON file from the deployment you already run.
One Agent Passport is one logical AI agent operated by your organisation. Publish it once, from the deployment that already exists, and the identity is readable by anyone — including systems that will never run your code.
Where next
Where next.
- Free Agent PassportFree · Permanent · No card. What it includes, and how to start.Go
- FrameworksPublish an agent identity from the framework you already use.Go
- Agent TrustFree local inspection of what your agents can reach.Go
- Every product for agentsEach with its live state, its price and its own TrustOps route.Go
£0 · No card required · Permanent, not a trial.