FAQ
Questions, answered plainly.
What a free Service & Workload Passport costs, what it identifies, who can check it, what you would ever pay for — and what an ECZ-ID is not.
Getting started
- What does a free Service & Workload Passport cost?
- £0. It is permanent, not a trial, and no card is required. You pay only if you later add scale, assurance or specialist products.
- What does one Service & Workload Passport identify?
- One Service & Workload Passport is one logical service or workload your organisation operates. Pods, replicas, regions, environments and deployments of that workload are not separate Passports.
- Where do I get one?
- In TrustOps, which owns every free door and every purchase. Each family's free door opens there when TrustOps publishes it as open; this site explains the Passport and never issues an identity itself.
- Do I need an organisation record first?
- No. Your organisation's ECZ-ID Business Passport — Declared — FREE is reused if you have one, or created with your first Passport. It is the Parent every Passport hangs from.
- What can every organisation hold, free?
- Every organisation starts with one ECZ-ID Business Passport — Declared — FREE. Each of the seven family Passports — Agent, MCP, Plugin, API, IoT, SDK and Service & Workload — is free, and is taken in TrustOps once TrustOps publishes that family's door as open. Historical and specialist Passport products remain honoured for the organisations that hold them. They are not the launch acquisition model, and no family site offers them as a door.
Proof and publication
- Who can check the record for my service or workload?
- Anyone. Once you consent to publication, the Resolver serves the record as a page and as JSON, with no account and no key.
- What does the badge prove?
- It is a route to current proof: one click opens the live Resolver record. It is not a safety, quality, approval or certification mark.
- Is publication automatic?
- No. Nothing becomes public until you consent, and you can withdraw publication later.
- Is a verified binding verified for good?
- No. A binding is verified as of its Last verified time, and the record shows its Freshness. ECZ-ID does not renew a bound binding: once its proof method's freshness window has passed, the result is history and a new binding is the fresh proof. Re-check before reliance.
Paid capabilities
- What would I ever pay for?
- Capacity to operate more entities (AEC), a stronger organisation tier (Parent VERIFIED or ASSURED), monitoring, evidence, relationship intelligence, change awareness, business solutions and specialist digital products. All are optional.
- Where do prices come from?
- From the commerce projection TrustOps publishes. This site shows what that projection says on the date it was built, and TrustOps decides what can be bought at the moment of purchase.
- Does paying make my service or workload more verified?
- No. Payment ≠ proof. A paid capability changes what you can operate. A paid Parent tier opens ECZ-ID's checks on your organisation — never on the service or workload — and the record shows VERIFIED or ASSURED only after they pass; payment alone changes nothing on the public record.
What a Passport is not
- Does the Service & Workload Passport verify the service or workload?
- A DECLARED record states what your organisation says. A VERIFIED or ASSURED Parent verifies your organisation, not the service or workload. A binding completed through a live proof method shows control of the bound asset as of when it was last verified; it certifies nothing about the service or workload itself.
- Does ECZ-ID replace my existing identity systems?
- No. It complements your frameworks, protocols, OAuth, cloud IAM and workload identity, and stays outside the execution path.
- Does ECZ-ID enforce anything at runtime?
- No. OBSERVED ≠ ENFORCED. ECZ-ID records and publishes; it does not block, allow or approve anything in your runtime.
Services, workloads and runtime identity
- Does each pod, replica, cluster or region need its own Passport?
- No. One Service & Workload Passport is one logical service or workload your organisation operates. Pods, replicas, regions, environments and deployments of that workload are not separate Passports.
- Is the Passport a runtime credential?
- No. No workload authenticates with an ECZ-ID, and holding one grants no access. Workloads keep authenticating with their provider-native identity — SPIFFE, Kubernetes service accounts, Entra, AWS IAM or Google Cloud.
- Does ECZ-ID replace SPIFFE, service accounts or cloud IAM?
- No. Add ECZ-ID; replace nothing. Provider-native identity answers how a workload authenticates inside your runtime. The Passport answers which enduring service it is, who is accountable for it and where anyone can re-check that.
- What does the public record reveal about my infrastructure?
- No cloud account, subscription, project, tenant or cluster identifier, and no credential of any kind. Publication requires your consent, and you can withdraw it.
- What happens to the identity when we migrate to another cloud?
- Nothing. The ECZ-ID stays the same. Bindings change to reflect where the service is now reached: a new public endpoint is bound and, once proved with a Domain /.well-known file or DNS TXT record, the Resolver shows when it was last verified and when a re-check is due. Runtime identities linked through Workload Identity Federation stay declared and unpublished.
- Does secretless migration mean every secret goes away?
- No. It replaces eligible long-lived credentials with short-lived, provider-issued workload identity. Database passwords, third-party API keys and signing keys each need their own treatment.
- Do Microsoft, AWS or Google endorse ECZ-ID?
- No. They are named to describe what their identity systems do. No partnership, endorsement or certified integration is implied.
The distinctions the estate keeps
- OBSERVED ≠ ENFORCED
- An observed state records what was seen, and when. ECZ-ID does not sit in your execution path and enforces nothing at runtime.
- Passport ≠ Binding
- The Passport is the one enduring identity. A binding records an asset it is known by; adding one never creates a second identity.
- Binding ≠ Authority
- A binding records that a relationship was declared or evidenced. It does not grant, prove or imply authority to act.
- Binding ≠ Certification
- A verified binding shows control of an asset when it was last verified. It certifies nothing about the asset's safety, quality or compliance.
- Payment ≠ Proof
- Buying a capability changes what you can operate. Payment alone never changes what the public record proves: a paid Parent tier opens ECZ-ID's checks on your organisation, and the record shows VERIFIED or ASSURED only after they pass.
- Badge = route to proof
- A badge is a link to the current Resolver record. It is not a certification mark, a safety rating or an approval.