Skip to content
ECZ-IDService & Workload
Free Passport: Get a FREE Service & Workload Passport

Logical identity

Infrastructure is ephemeral. Accountability is not.

A service outlives every pod, cluster and region it runs in — sometimes every cloud. One ECZ-ID identifies that enduring service and the organisation accountable for it, while the provider-native workload identity underneath keeps doing exactly what it does today.

The signature chain

Organisation, service, Passport, bindings, native identities, proof.

Read it in order. Cards marked Enduring are public and accountable; cards marked Runtime are the provider-native layer underneath, which can be replaced without the identity 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.

Over a year

What changes underneath a service, and what survives it

Every item under Changes will change for a production service, most of them more than once. None of them changes its ECZ-ID.

Changes — provider-native and replaceable

  • Pods, replicas and the nodes they run on
  • Deployments, images and versions
  • Clusters — rebuilt, upgraded, replaced
  • Regions and availability zones, after a failover
  • Clouds and platforms, after a migration
  • Runtime identities and the credentials they are issued
  • Hostnames, load balancers and IP addresses

Stays — enduring and accountable

  • The organisation accountable for the service
  • The logical service your customers depend on
  • Its ECZ-ID — the same identifier, from its first day
  • Its public Resolver record, re-checkable by anyone
  • Its published relationships to the APIs, SDKs and agents around it
  • The evidence of what changed, and when

The subject

The enduring service, not the thing currently running

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

What is never a separate identity

Pods, replicas, regions, environments and deployments of that workload are not separate Passports. A rotating SPIFFE identity, a Kubernetes service account and a short-lived cloud credential are runtime identities the service runs under — never the subject itself.

Why that is the useful unit

The thing a counterparty depends on is the service, not the process serving it this afternoon. An identity pinned to the process would be correct and useless; one pinned to the service outlives every deployment of it.

What the record does not contain

Nothing from inside your infrastructure is published

A public identity for an internal workload is only safe if publishing it gives away nothing about the inside.

No internal identifier, no credential

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.

A binding records an asset the service is known by. A binding proved with a Domain /.well-known file or DNS TXT record shows control of that asset as of its Last verified time, and nothing more: it grants no access and confers no authority. Re-check before reliance.

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.

ECZ-ID complements your frameworks, protocols, OAuth, cloud IAM and workload identity. It replaces none of them and stays outside the execution path.

Go deeper

Where the argument continues

Get a FREE Service & Workload Passport

Where next

Keep going with ECZ-ID Service & Workload.

Get a FREE Service & Workload Passport