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 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.
Connect the places it already exists
Your service or workload 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 published service or status page
- public documentation for the service
- a public endpoint you declare
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.
Pods, replicas, regions, environments and deployments of that workload 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 service or workload 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 Service & Workload Passport is one logical service or workload your organisation operates.
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.
Pods, replicas, regions, environments and deployments of that workload 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.
The neighbouring identity open to you today is Agent.
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.
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 our logical services linked to the workload identities they already run under.
Workload Identity Federation
Links the ECZ-IDs of your logical services to the workload identities they already run under.
Boundary: It never replaces or controls your cloud IAM, SPIFFE identities or service accounts.
Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.