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

Interoperability

Add ECZ-ID. Replace nothing.

Provider-native workload identity answers how a workload authenticates inside your runtime. The Service & Workload Passport answers which enduring service it is, who is accountable for it, what is bound to it and where anyone can re-check it. Add ECZ-ID. Replace nothing.

Two questions

Native where you operate. ECZ-ID where you interoperate.

Provider-native identity and an ECZ-ID answer different questions. You need both answers; nothing in provider-native workload identity is removed to make room for the ECZ-ID Service & Workload Passport.

Stays exactly where it is

Provider-native workload identity

How does this workload authenticate inside the runtime or provider?

  • Which identity the running process holds right now — a SPIFFE ID, a Kubernetes service account, a managed identity, an IAM role.
  • Short-lived credentials, issued and rotated by your platform.
  • What that process may call, inside one trust domain, cluster, tenant, account or project.
  • Readable only inside that boundary, by design.

SPIFFE and SPIRE · Kubernetes service accounts · Entra · AWS IAM · Google Cloud · OAuth and OIDC

Added beside it

ECZ-ID Service & Workload Passport

What enduring logical service or workload is this?
One persistent ECZ-ID for the logical service, unchanged by pods, clusters, regions, clouds and runtime replacements.
Who is accountable for it?
The organisation on the record as its operator, through its ECZ-ID Business Passport — Declared — FREE. VERIFIED or ASSURED strengthens the organisation if you choose, never the service.
What systems and identities are bound to it?
Its public endpoints and pages as bindings, each declared until proved with a Domain /.well-known file or DNS TXT record and then shown with when it was last verified; the runtime identities it runs under, declared through Workload Identity Federation and never published.
What public proof is current?
The Resolver record, with the time it was read and, for each verified binding, when it was last verified and when a re-check is due. The record itself says it is not a verdict and must be re-checked before reliance.
Where can a counterparty re-check it?
On the Resolver, as a page and as JSON, with no account and no key — reached from a badge, a QR code or a link.

Named, one by one

What each already does inside your runtime, and what an ECZ-ID adds outside it

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

  • SPIFFE and SPIRE

    Inside your runtime: Attest each workload and issue it short-lived SVIDs — X.509 or JWT — for a SPIFFE ID in your trust domain, used for mutual TLS and service-to-service authentication.

    What an ECZ-ID adds outside it: A stable public identity for the enduring service behind those SPIFFE IDs, and the organisation accountable for it.

  • Kubernetes service accounts

    Inside your runtime: Give each pod an identity in its cluster, with projected, audience-bound and time-limited tokens for the API server and, through federation, for cloud APIs.

    What an ECZ-ID adds outside it: One identity for the logical workload that stays the same while pods, deployments and whole clusters are replaced.

  • Microsoft Entra managed identities and workload identities

    Inside your runtime: Let Azure resources, and external workloads through workload identity federation, obtain Entra tokens without stored secrets, governed by role assignments in your tenant.

    What an ECZ-ID adds outside it: An identity for the service that resolves outside the tenant, for parties with no access to it.

  • AWS IAM roles for workloads

    Inside your runtime: Give workloads temporary credentials from AWS STS — through instance profiles, IAM roles for service accounts or EKS Pod Identity, for example — scoped by policy inside your accounts.

    What an ECZ-ID adds outside it: A public identity a counterparty can read with no access to your accounts, naming the organisation accountable for the service.

  • Google Cloud service accounts and workload identity federation

    Inside your runtime: Let workloads on Google Cloud, GKE or other platforms act as a service account with short-lived tokens, without exported service-account keys.

    What an ECZ-ID adds outside it: A public identity readable outside your projects, naming the organisation that operates the service.

  • OAuth 2.x and OpenID Connect

    Inside your runtime: Issue access tokens to services — with the client-credentials grant, for example — and OIDC identity tokens to CI pipelines for federation.

    What an ECZ-ID adds outside it: A durable public record of the service and its operator that outlives any token and needs none to read.

  • Runtime credentials — keys, certificates and tokens

    Inside your runtime: Authenticate one process or one connection, for as long as each is valid.

    What an ECZ-ID adds outside it: Nothing to authenticate with. A Passport is not a credential; it identifies the service a credential is used by.

Providers and projects are named only to describe what their identity systems do. No partnership, endorsement, certified integration or joint product is implied.

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.

Who holds which truth

Core writes it. TrustOps acquires, the Dashboard operates, the Resolver proves.

Who holds which truth, with the Developer Gateway for integration, and the distinctions that keep them apart.

  1. Canonical truth

    ECZ-ID Core

    Writes the identity, its state and its evidence. Nothing on this website issues, edits or stores an identity.

  2. Acquisition, payment, entitlement

    TrustOps

    Owns acquisition, payment and entitlement. Every free door and every purchase happens there, and nowhere else.

  3. Operation

    Dashboard

    The signed-in estate console where you manage Passports, bindings, capacity and the capabilities you hold.

  4. Public proof

    Resolver

    Public, read-only proof. Anyone can open the current record and its JSON with no account, and re-check it before relying on it.

  5. Documentation and integration

    Developer Gateway

    Schemas, client guidance and integration reference for resolving from your own code.

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

Adjacent identities

The Passports that surround this one

Each is a separate subject with its own operator and its own identity. None is issued for you, and none is implied by holding this one.

  • ECZ-ID API Passport™

    Services expose APIs. Each API is identified separately from the workload that serves it.

  • ECZ-ID SDK Passport™

    Services are built from SDKs and libraries, each of which can carry its own publisher identity.

  • ECZ-ID Agent Passport™

    Agents increasingly run as workloads. The agent and the workload hosting it are two subjects, not one.

Go deeper

Where the argument continues

Where next

Keep going with ECZ-ID Service & Workload.

Get a FREE Service & Workload Passport