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 without a version: the version is history, and history is not identity.
The canonical source repository
Host, owner and repository name. Not a branch and not a commit — those move, and the subject does not.
A container or OCI reference
Where a library is also distributed as an image, that reference is a binding of the same kind as a registry listing.
The publishing pipeline
A workload identity in your CI provider can be bound, so a reader can see which pipeline is declared to publish this library.
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.
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.
