ECZ-ID Service & Workload Passport Overview and Customer Guide

• WHAT STAYS DURABLE

  The Service & Workload ECZ-ID for the intended service/workload/runtime object where continuity is appropriate.

• WHAT CAN CHANGE

  Provider-native workload IDs, cloud account/project/subscription references, clusters/namespaces/service accounts, runtime/deployment/service bindings, environment, current state and evidence.

• RESOLVER

  Public, read-only proof a human or machine can independently re-check.

• DASHBOARD

  Authenticated customer control for permitted lifecycle and estate actions.

• WITHOUT A PERSISTENT IDENTITY

  Teams may rely on a service name, provider-native workload ID, cloud resource ID, cluster/namespace reference, service account, container/workload ID or runtime endpoint - each tied to one provider/runtime context and potentially mutable.

• WITH SERVICE & WORKLOAD PASSPORT

  The workload can present a stable ECZ-ID with bounded organisation/owner/operator responsibility, current state, bindings and evidence that counterparties can resolve again.

• RESPONSIBILITY CAN ANSWER

  Which organisation, owner or operator claims responsibility for this service/workload identity?

• RESPONSIBILITY DOES NOT MEAN

  Every deployment, authority, security property or third-party claim has been independently verified.

• OWNER/OPERATOR CHANGES

  Owner/operator responsibility can change while the canonical service/workload identity remains stable where the underlying object remains the same.

• PARENT CONTEXT

  Links the Service & Workload Passport to the responsible organisation/Parent where present.

• EVIDENCE

  Supports bounded claims according to source, scope and freshness.

• RE-CHECK

  Resolve again when organisation/owner/operator responsibility matters to the decision.

• CLOUD CONTEXT

  Cloud account, project or subscription reference where supported.

• RUNTIME IDENTITY

  Provider-native workload ID, namespace, service account, container or workload reference where supported.

• DEPLOYMENT

  Deployment, service or runtime reference where supported.

• ENVIRONMENT

  Cluster, namespace, runtime or environment relationship where supported.

• AUTHORITY CONTEXT

  Supported authority/delegation or policy context where present and evidenced.

• EVIDENCE LINK

  Reference that supports a bounded claim about the service/workload identity.

• IDENTITY PERSISTS

  The ECZ-ID can remain stable across supported provider, account/project, cluster, namespace, runtime and deployment changes when the underlying service/workload object remains the same.

• CONTEXT CHANGES

  Published deployment/lifecycle state, bindings and evidence should be re-checked when freshness matters.

• GOOD CONSUMER BEHAVIOUR

  Read source, scope and freshness; re-resolve before consequential adoption or upgrade decisions.

• UNSAFE SHORTCUT

  Assuming an old deployment, runtime, provider binding or owner/operator context is still current because the ECZ-ID itself is unchanged.

• IDENTITY

  Which service/workload object is this?

• RESPONSIBILITY

  Who claims publication/responsibility?

• LOCAL POLICY

  Is this workload/deployment permitted in this environment?

• SECURITY CONTROLS

  Are authority/policy context, signing, vulnerability, runtime-policy and runtime requirements satisfied?

• PROVIDER MIGRATION

  Preserve service/workload identity when cloud/provider context changes.

• CLUSTER/RUNTIME MIGRATION

  Keep the same ECZ-ID while supported cluster, namespace, runtime or provider bindings change.

• DEPLOYMENT VERIFICATION

  Connect a stable service/workload identity to current runtime/deployment context.

• ENTERPRISE WORKLOAD REVIEW

  Give architecture/security teams a re-checkable identity anchor for a service/workload.

• MACHINE CONSUMPTION

  Allow automation to resolve bounded service/workload identity/context before service/workload deployment or migration decisions.

• CROSS-PROVIDER / CROSS-RUNTIME PORTABILITY

  Treat provider, runtime and provider-native workload IDs as bindings rather than the authority root.

• BEFORE

  Consumers know the service/workload by ECZ-ID plus provider, account/project, cluster/namespace, runtime and deployment bindings.

• AFTER

  The Service & Workload ECZ-ID remains stable; supported provider/runtime/deployment bindings and evidence are updated and Resolver reflects the current record.

• CONSUMER ACTION

  Re-resolve before relying on the new provider/runtime/deployment context.

• SECURITY ACTION

  Validate workload authentication, IAM/authorization, container/image integrity, vulnerability/configuration and local runtime approval independently.

• STRONG FIT

  Services/workloads that move across providers, accounts/projects, clusters, namespaces, runtimes or deployments where durable identity matters.

• SECURITY FIT

  Teams that need a stable object identity before applying separate IAM, workload-security and runtime controls.

• DEVELOPER FIT

  Tooling that needs a machine-resolvable service/workload identity independent of one namespace/service-account/container reference.

• LOWER-VALUE FIT

  Single-use or ephemeral service/runtime/deployment references where persistent cross-context identity brings little benefit.

• If absent, stale or mismatched:

  challenge, deny, pin or re-resolve

• If required proof is present and fresh:

  evaluate local workload/runtime policy and proceed

MACHINE-READABLE ROUTE

GET https://api.ecocitizenz.com/api/p/{ecz_id}.json

• IF REQUIRED PROOF IS PRESENT

  Evaluate the decision using the returned state, bindings and evidence plus your local workload/runtime policy.

• IF REQUIRED PROOF IS ABSENT

  Treat it as not established; challenge, pin, deny or seek additional evidence rather than infer.

• OBJECT

  Service / workload / runtime identity.

• PERSISTENT IDENTITY

  One canonical ECZ-ID can survive provider/runtime/deployment reference and deployment changes where object continuity holds.

• RESPONSIBILITY

  Organisation/Parent and owner/operator context where present.

• BINDINGS

  Provider-native workload IDs, cloud account/project/subscription, cluster/namespace/service-account/container, runtime/deployment/service and documentation references where supported.

• EVIDENCE + STATE

  Bounded, point-in-time context; source, scope and freshness matter.

• BOUNDARY

  Not workload safety, configuration correctness, runtime/image integrity, availability or permission to perform an action.