Skip to content
ECZ-IDSDK

After issuance

Issuance is the start of the record, not the end of the job.

A Passport nobody points at is a record nobody reads. This is what the first week with one actually looks like — and none of it needs anything beyond the free identity until your estate asks for more.

  1. Let anyone check it

    Publish the record, then share it. Anyone can then open the same page you can, or read the same record as JSON, with no account and no key. The badge, the QR code and the share link come with the free Passport.

    The same record answers a machine at https://api.ecocitizenz.com/api/p/{ecz_id}.json — no account, no key, and nothing metered about reading it.

    Publishing the record is your decision. Nothing becomes public until you consent, and you can withdraw publication later.

    Pattern you implementQuoting the identifier where people already look — a README, a documentation page, a listing, a signature — is yours to do. We publish the record; where you point at it is your decision.

    A Resolver record is not proof. It publishes what is currently declared and what evidence exists, with the time it was read — is_proof is false and recheck_before_reliance is true. Re-check before you rely on it.

  2. Connect the places it already exists

    Your SDK or library almost certainly already appears in public somewhere. Record those places against the one identity, so the same thing stops being a different thing in each of them. Each binding records where it was learned.

    • a package registry listing
    • the canonical source repository
    • an OCI registry reference
    • your published documentation

    Illustrative. This is the shape a record of this kind can take, not a live estate — a new Passport starts with no bindings and no relationships, and shows only what its operator chooses to publish.

    Releases, versions and registry channels of that library are not separate Passports.

  3. See what it is connected to

    Your organisation, this identity and everything bound to it now read as one picture — beside the other identities it legitimately sits next to, each with its own operator.

    A relationship is not permission.

  4. Work out what genuinely needs an identity of its own

    Some of what surrounds your SDK or library is another representation of the same thing. Some of it is a different subject, with a different operator and a lifecycle of its own. Only the second kind is a second Passport.

    When something deserves a Passport of its own

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

    A second Passport is for a second logical subject — something with its own operator and its own lifecycle. It is never another representation of this one.

    Releases, versions and registry channels of that library are not separate Passports.

    Versions, replicas, endpoints, listings and deployments are bindings. They never consume capacity and never become a second Passport.

    Related Passports are suggested, never issued for you. Each is its own free identity, taken with its own deliberate click.

  5. Manage everything you hold in one place

    One signed-in console holds the identities your organisation holds, what they are bound to and what their records currently say. It is also where your organisation's current configuration lives.

  6. Add more only when the estate gives you a reason

    A free Passport exists and resolves whether or not you use any AEC. Nothing below is already running, none of it is needed to keep what you hold, and declining it never changes an identity you have.

    None of this is switched on by default. A free Passport includes evaluation you ask for, not monitoring that runs on a schedule, and anything ongoing starts only when you choose it in TrustOps.

    • I need to manage more entities in production.

      AEC — Active Entity Capacity

      One AEC is one actively managed production entity with live bindings and current state.

      A free Passport exists and resolves whether or not you use any AEC.

    • I need the organisation behind these identities independently checked, not just declared.

      Parent VERIFIED and ASSURED

      Independent verification of the organisation behind your Passports. VERIFIED suits production use; ASSURED is the higher-assurance posture for larger or more sensitive estates.

      Boundary: It verifies your organisation. It never verifies an agent, a server or any other child identity, and it never changes an ECZ-ID.

      Included free: Every Passport starts with a free DECLARED Parent — created for you if your organisation has none.

    • I need to show where each package we publish came from.

      SDK Publisher & Provenance

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

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

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

    Everything else relevant to SDK Passports