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.
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 documentation page, a product page, a signature — is yours to do. We publish the record; where you point at it is your decision.
The Resolver is public, read-only proof of what is currently declared and verified, with the time it was read. A record is not a verdict, and the record itself says so and asks to be re-checked. Re-check before reliance.
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. Where a live proof method fits, complete it, so the record shows the binding as verified, with when it was last verified.
- 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.
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.
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.
None of what is listed above is a second Passport, and none of it consumes AEC. The public places this one already appears are recorded as bindings on it instead.
Related Passports are suggested, never issued for you. Each is its own free identity, taken with its own deliberate click.
The neighbouring Passports open to you today are the API, Plugin and Service & Workload Passports.
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.
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. Paying opens ECZ-ID's checks, and the record shows the tier only after they pass — payment alone changes nothing on it.
Boundary: It verifies your organisation. It never verifies the subject of any child Passport, and it never changes an ECZ-ID.
Included free: Your organisation's ECZ-ID Business Passport — Declared — FREE is the Parent every Passport starts from, 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.
Where next
Keep going with ECZ-ID SDK.
- ProductsEvery SDK product and service, each with its own page.Open
- The free SDK PassportWhat it establishes, what it never says, and how it is issued.Open
- Verify an ECZ-IDRead a live record on the public Resolver — no account, no key.Open
- Build and integrateSBOM binding on the Developer Gateway.Open (opens in a new tab — developers.ecocitizenz.com)