Free identity
The free Service & Workload Passport
One Service & Workload Passport covers one enduring logical service — never a pod, a replica, a process or a region. This page is the whole of what the free identity establishes, and what it deliberately does not say.
The subject
One Service & Workload Passport is one service or workload
What never becomes a second Passport
Pods, replicas, regions, environments and deployments of that workload are not separate Passports.
The shape of the identifier
ECZ-XX-XXXXXX::SERVICE_WORKLOAD_PASSPORT-XXXXXX
A pattern, not a real record. The identifier of your organisation’s ECZ-ID Business Passport (the Parent) comes first, and the Service & Workload Passport follows the :: separator.
Across changing infrastructure
Where the free Passport sits in the chain
From the accountable organisation to public proof — across whatever runs underneath.
Organisation
The organisation accountable for the service, on the record as its operator through its ECZ-ID Business Passport — Declared — FREE. VERIFIED and ASSURED strengthen the organisation, never the service.
Enduring · public · accountable
operates
Logical service or workload
The enduring thing your customers depend on — the checkout service, not the pod serving it this afternoon.
Enduring · public · accountable
is identified by
ECZ-ID Passport
One persistent ECZ-ID for that service. It does not change when the infrastructure does.
Enduring · public · accountable
is bound to
Cloud and runtime bindings
Public endpoints and pages as bindings, each verified once proved with a Domain /.well-known file or DNS TXT record and then shown with when it was last verified; the clusters, regions and clouds it runs in, declared through Workload Identity Federation and never published.
Runtime · provider-native · replaceable
runs under
Provider-native workload identities
SPIFFE IDs, Kubernetes service accounts, Entra managed identities, AWS IAM roles, Google Cloud service accounts — still authenticating the workload, unchanged and unpublished.
Runtime · provider-native · replaceable
is proved on
Resolver
Public, read-only proof of the service and its operator, as a page and as JSON — re-checked before anyone relies on it.
Enduring · public · accountable
extends into
Graph, Watch and evidence
Relationships to the APIs it exposes and the SDKs it is built from, change awareness for those who rely on it, and LedgerCore evidence of what changed and when.
Enduring · public · accountable
The runtime underneath can be replaced; the organisation, the service and its ECZ-ID stay. The Passport is never a runtime credential: workloads keep authenticating with their provider-native identity, a binding grants no access, and no cloud account, project, tenant or cluster identifier reaches the public record.
Platforms, standards and providers are named to show where ECZ-ID sits alongside them. Naming them implies no endorsement by, or partnership with, their owners.
Included
What the free Passport establishes
- A persistent ECZ-ID for the service or workload.
- Your organisation on the record as its operator. Its ECZ-ID Business Passport — Declared — FREE is created if you do not already have one.
- A public Resolver record anyone can open, and the same record as machine-readable JSON.
- A badge, a QR code and a share link.
- Basic bindings to the public places where your service or workload already appears.
- Lifecycle and current public state, evaluated on demand.
- Claim and recovery.
- Basic participation in the Digital Entity Graph.
- Essential lifecycle evidence, kept in LedgerCore.
Publishing the record is your decision. Nothing becomes public until you consent, and you can withdraw publication later.
Everything included free
Each free capability, in full
- ResolverPublic, read-only proof of identity for your service or workload, for anyone who asks.Read the full page
- Badge, QR and share proofPut a route to current proof wherever people already meet you.Read the full page
- Machine-readable identityThe same record, as JSON any program can read.Read the full page
- BindingsEvery place your service or workload appears, tied to one identity.Read the full page
- Digital Entity GraphSee how your service or workload relates to the entities around it.Read the full page
The flow
How to get one
Take the Passport
Start in TrustOps with one sign-in. Your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created, and your service or workload gets its free Service & Workload Passport — one ECZ-ID that does not change.
Bind an asset
Name an asset your service or workload is known by — for example a published service or status page. Binding never creates a second identity. Each binding records where it was learned.
Choose and prepare a proof method
Choose the live proof method that fits the asset: Domain /.well-known file or DNS TXT record. Places no live method reaches are marked Planned. Your ECZ-ID console gives you the exact value to publish for that method.
Complete the proof and review
Publish it on the asset you control, then tell ECZ-ID the proof is in place. The binding is reviewed before anything about it is published as verified.
ECZ-ID verification, then the Resolver
ECZ-ID checks the published proof and records the outcome with the time it checked. The Resolver then shows the binding with its proof method, its Last verified date and its Re-check due date — to anyone, with no account and no API key.
Operate — re-check before reliance
Keep the proof in place. A binding is verified as of a time, not indefinitely: ECZ-ID does not renew a bound binding, and after its method's freshness window a new binding is the fresh proof — re-check before reliance. Publish the ECZ-ID where people and machines already look. Strengthen only if it is useful: Parent verification, monitoring, evidence and authority are optional, and none is needed to hold a Passport.
The boundary
What the Passport deliberately does not say
DECLARED ≠ VERIFIED
A DECLARED record states what your organisation says about itself, with the date it said it. It is not the outcome of an independent check.
Passport ≠ Binding
The Passport identifies the service or workload. A binding records a public place where it already appears. Adding a binding never creates a second identity.
Binding ≠ Authority
A binding shows that a relationship has been declared. It does not grant, prove or imply authority to act.
Parent verification ≠ Service & Workload verification
A VERIFIED or ASSURED Parent verifies your organisation. It does not verify the service or workload.
Passport ≠ runtime credential
An ECZ-ID Passport is never a cloud runtime credential. No workload authenticates with it, holding one grants no access to anything, and your provider-native identities keep doing exactly what they do.
No cloud account, subscription, project, tenant or cluster identifier, no internal hostname and no credential of any kind appears on a public Service & Workload record. Where a runtime identity is linked, the link is recorded as a relationship, not a copy of your configuration.
An ECZ-ID does not make anything safe, certified, approved or compliant, and holding one does not make you compliant with anything.
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.
Where next
Keep going with ECZ-ID Service & Workload.
- ProductsEvery Service & Workload product and service, each with its own page.Open
- The free Service & Workload 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 integrateAPIs, AI, Data & Software on the Developer Gateway.Open (opens in a new tab — developers.ecocitizenz.com)
