Included free · One identity, many places · ECZ-ID Service & Workload

Bindings

Every place your service or workload appears, tied to one identity.

A binding records a public place where your service or workload already appears — a published service or status page or public documentation for the service — against its one ECZ-ID. Where a live proof method reaches the place, completing the proof shows the binding as verified, with when it was last verified. Adding a binding never creates a second identity.

Get a FREE Service & Workload Passport Verify an ECZ-ID All Service & Workload products

Type: Included free
Price: £0 — included with every free Passport
Acquired and paid in: TrustOps
Operated in · proved by: Dashboard · Resolver

The problem

Why it matters.

The same service is reached at several endpoints, documented in several places and runs under several runtime identities. Readers cannot tell these belong to one service, or which organisation answers for it.

Built for

Teams whose service or workload appears in more than one place, under more than one name.
Teams that rename or move a surface without changing what the service or workload is.
Reviewers who need to know that two appearances are one service or workload.

What changes

One identity across every place it appears.
Every bound place pointing back to the same public record.
A clear record of where each binding was learned, which are verified, and as of when.

What you receive

Concrete deliverables, not a vague trust score.

Basic bindings with every free Passport.
The source each binding was learned from.
The live proof methods for Service & Workload Passports: Domain /.well-known file or DNS TXT record.
Bindings shown on the public record, with consent.

Bindings on one record

Identity: ECZ-XX-XXXXXX::SERVICE_WORKLOAD_PASSPORT-XXXXXX
Verified binding: a published service or status page
Verified binding: public documentation for the service
Proof method: Domain /.well-known file or DNS TXT record — whichever was completed
Last verified: YYYY-MM-DD
Re-check due: YYYY-MM-DD
Learned from: The source of each binding, recorded

Illustrative structure with placeholder values. A declared binding shows no Last verified date; a verified one shows when it was last verified and when a re-check is due.

How it works

A short path from need to something usable.

Passport — Your service or workload holds one free Service & Workload Passport, issued through TrustOps and written by ECZ-ID Core.
Bind 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.
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.
Prepare — Your ECZ-ID console gives you the exact value to publish for that method.
Complete proof — Publish it on the asset you control, then tell ECZ-ID the proof is in place.
Review — The binding is reviewed before anything about it is published as verified.
ECZ-ID verification — ECZ-ID checks the published proof and records the outcome with the time it checked.
Resolver — The public record shows the binding, its proof method, when it was last verified and when a re-check is due.
Operate — 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.

How it relates to your Passport

Basic bindings record the public places a service is seen, and are part of the free Passport. Each can be proved with a Domain /.well-known file or DNS TXT record; a verified binding is shown with when it was last verified and when a re-check is due, and until then it is shown as declared. Linking the provider-native identities it runs under — SPIFFE IDs, Kubernetes service accounts, cloud workload identities — is Workload Identity Federation, an optional capability; those links are declared, and none of those identifiers is published. AEC counts the services you actively manage with live bindings; PulseGuard can evaluate the current state of bound surfaces; ECZ-ID Watch tells followers when they change.

Use cases

Binding a published service or status page to its one ECZ-ID.
Binding public documentation for the service to its one ECZ-ID.
Binding a public endpoint you declare to its one ECZ-ID.

Price

Included free, with every Passport.

£0. It is part of the free Service & Workload Passport — permanent, not a trial, and no card is required.

After you take it

TrustOps acquires
Take the free Passport in TrustOps; your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created.
Dashboard operates
Operate it in the Dashboard: publish, bind and copy your proof links.
Resolver proves
Anyone resolves the current record on the Resolver.

Privacy, security and evidence

What is collected, published and kept.

Each binding records where it was learned.
A verified binding shows its proof method and when it was last verified; a declared one is shown as declared.
Publication of bindings follows the same consent as the record.

Boundaries

The claims stop here.

Passport ≠ Binding. A binding records an asset; it is never a second identity.
Binding ≠ Authority. A binding does not grant, prove or imply authority to act.
Binding ≠ Certification. A completed proof shows control of the named asset when it was checked. It is not a certification, does not grant authority, and says nothing about safety or quality.
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.
A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.

Integrations and questions

Works with what you already run.

A published service or status page — Domain /.well-known file or DNS TXT record.
Public documentation for the service — Domain /.well-known file or DNS TXT record.
A public endpoint you declare — Domain /.well-known file or DNS TXT record.

Does each pod, cluster or region need its own Passport?: No. Pods, replicas, regions, environments and deployments of that workload are not separate Passports.
Are my cloud workload identities published as bindings?: No. Basic bindings record public places the service appears. Linking provider-native identities is Workload Identity Federation, and no account, project, tenant or cluster identifier reaches the public record.
Does a binding prove I control the endpoint?: Only a binding completed through a live proof method shows control of that asset, and only as of its Last verified time. A declared binding records the relationship and where it was learned. Neither grants authority.
Which places can a live proof method reach today?: A published service or status page — Domain /.well-known file or DNS TXT record. Public documentation for the service — Domain /.well-known file or DNS TXT record. A public endpoint you declare — Domain /.well-known file or DNS TXT record. A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.

Start with a free Service & Workload Passport.

£0 · No card required · Permanent, not a trial.

Get a FREE Service & Workload Passport Verify an ECZ-ID