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

Works alongside

What an ECZ-ID SDK Passport sits beside

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.

Adjacent systems

What each already does, and what the Passport adds

ECZ-ID complements your frameworks, protocols, OAuth, cloud IAM and workload identity. It replaces none of them and stays outside the execution path.

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

    What it does
    Distribute the versions of your library.
    What an ECZ-ID adds
    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 an ECZ-ID adds
    A binding from the repository to the enduring subject, recorded with where it was learned.

Developer toolchain

CI/CD, trusted publishing, attestations and SBOM tooling

The rest of an SDK publisher's toolchain, row by row: what it already does, and what the Passport adds beside it.

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.

Adjacent identities

The Passports that surround this one

Each is a separate subject with its own operator and its own identity. None is issued for you, and none is implied by holding this one.

  • ECZ-ID API Passport™

    Most SDKs wrap an API. The API keeps its own identity, whichever SDKs call it.

  • ECZ-ID Plugin Passport™

    SDKs are the building blocks of plugins, and each plugin is identified in its own right.

  • ECZ-ID Service & Workload Passport™

    Libraries run inside services and workloads, which are separate enduring subjects.

Where next

Keep going with ECZ-ID SDK.

Get a FREE SDK Passport