Skip to content
ECZ-IDSDK
Verify an ECZ-ID

Origin

Publisher identity and provenance

A consumer tracing a package back to its publisher is, today, mostly guessing from a registry account name. Provenance answers the question that guess is standing in for: who publishes this, and is that the same publisher as the last release.

What it answers

Origin, continuity and the organisation behind both

Three questions that a public record can answer, and that nothing in a registry currently answers on its own.

  • Who publishes this

    The organisation on the record as the library's operator, with the date it declared itself.

  • Is this the same library

    One identity across registries and renames, so continuity is a fact on a record rather than an inference from a name.

  • Where it is distributed

    Each registry channel and the canonical repository, declared by the publisher rather than assembled by a third party.

  • Has anything changed

    Decisive lifecycle transitions are kept as evidence, so a consumer can see that a publisher relationship changed rather than discovering it later.

The part that matters most

Provenance is not a security review

An ECZ-ID does not make anything safe, certified, approved or compliant, and holding one does not make you compliant with anything.
  • No code has been read, scanned, tested or audited by anyone because a library holds an ECZ-ID.
  • A record says nothing about the dependencies a library pulls in, or about anything they do.
  • It is not a signature and it does not replace one. Artefact signing and attestation live in your registry and your pipeline, and they answer a different question.
  • It does not mean a registry has reviewed anything. Registries run their own processes, and an ECZ-ID is not an input to any of them.
  • A VERIFIED or ASSURED Parent verifies the publishing organisation. It does not verify the library.

Optional

SDK Publisher & Provenance

Publisher identity and provenance across the SDKs and packages you publish.

The boundary

Provenance records where a package came from. It is not a security audit of its code.

Nothing here is required to hold a free SDK Passport, to publish its record or to have it resolved. Publisher-level provenance is useful when you publish enough libraries for the estate to be the unit; one library needs one Passport and nothing else.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.