Skip to content
ECZ-IDSDK

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

One SDK Passport is one logical SDK, library or package your organisation publishes.

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

The Passport identifies the SDK or library. A binding records a public place it already appears. Adding a binding never creates a second identity.
  • 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

Developers ask this first, so it is answered before anything else is offered.

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

An SDK sits between subjects that each have their own identity and their own operator.

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.

The identities that surround an SDK Passport