Distribution
One library, every registry
The same library is published to several registries, in several languages, under several account names. One ECZ-ID names the library and the organisation behind it, and each registry channel becomes a binding against that one identity.
The subject
The library is the subject, not the package
What stays the same
The identity survives a major version, a rename, a move to a new registry and a change of maintainer. It is the continuity a consumer currently has to infer.
Where the line falls
Releases, versions and registry channels of that library are not separate Passports. A different library is a second Passport — including a sibling package in the same monorepo, if a consumer would reasonably call it a different library.
Bindings
A registry channel records where the library is distributed
A package registry listing
The ecosystem and the name, recorded as a declared binding without a version: the version is history, and history is not identity. The registry connector is Planned.
The canonical source repository
Host, owner and repository name, recorded as a declared binding. Not a branch and not a commit — those move, and the subject does not. The repository connector is Planned.
A container or OCI reference
Where a library is also distributed as an image, that reference is a declared binding of the same kind as a registry listing. Its connector is Planned.
The published documentation
Documentation on a domain you control is the place a live proof method reaches today (Domain /.well-known file or DNS TXT record), so this binding can be verified — as of its Last verified time, never for good.
Every one of these is recorded without a version. A release is an event against an enduring subject; it is not a new subject, and a record that minted one per release would be a changelog with extra steps.
A registry channel, a repository or an OCI reference recorded here is a declared binding, with the date it was learned; the connectors that would verify them are Planned. It does not mean the registry agrees, it does not mean the channel is current, and it grants nothing.
What a live proof method reaches today is a place on a domain you control, such as your published documentation: Domain /.well-known file or DNS TXT record. 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.
The honest answer
What there is to install today
There is no ECZ-ID client SDK published yet. No package name, no install command and no version is named anywhere on this site, because naming one would describe something that does not exist.
None is needed to hold an SDK Passport. The identifier and a link back to the Resolver record go into metadata a package already has — a manifest field, a project file, a README badge — and nothing is added to the execution path of anything.
When tooling exists, it will be published through the Developer Gateway, which is where integration reference for this estate lives and where it is kept current. Open the Developer Gateway (opens in a new tab)
Adjacent
A library is not the thing it wraps
A client library that wraps an API is a different subject from the API, which keeps one identity whichever SDKs call it. A library that a plugin is built on is a different subject from the plugin. A library running inside a service is a different subject from the workload.
Where next
Keep going with ECZ-ID SDK.
- ProductsEvery SDK product and service, each with its own page.Open
- The free SDK PassportWhat it establishes, what it never says, and how it is issued.Open
- Verify an ECZ-IDRead a live record on the public Resolver — no account, no key.Open
- Build and integrateSBOM binding on the Developer Gateway.Open (opens in a new tab — developers.ecocitizenz.com)