Skip to content
ECZ-IDService & Workload

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

One Service & Workload Passport is one logical service or workload your organisation operates.

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

The Passport is the enduring link between the organisation that answers for a service and the public proof anyone can re-check. The runtime underneath can change without it changing.

From the accountable organisation to public proof — across whatever runs underneath.

  1. 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

  2. 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

  3. is identified by

    ECZ-ID Passport

    One persistent ECZ-ID for that service. It does not change when the infrastructure does.

    Enduring · public · accountable

  4. 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

  5. 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

  6. 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

  7. 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

£0 · No card required · Permanent, not a trial.
  • 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.

The flow

How to get one

The binding law in 6 steps, from taking the Passport to keeping its proof current.
  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

These four distinctions are the whole reason the record is worth reading, and for a service or workload there is a fifth. A page may shorten its own copy; it may not weaken these.
  • 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.

Get a FREE Service & Workload Passport