ECZ-ID SDK Passport Overview and Customer Guide

• WHAT STAYS DURABLE

  The SDK ECZ-ID for the intended package/release family where continuity is appropriate.

• WHAT CAN CHANGE

  Repository, registry, publisher metadata, documentation, release/version context 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 package name, repository URL, registry coordinate or download location - each tied to one distribution context and potentially mutable.

• WITH SDK PASSPORT

  The package can present a stable ECZ-ID with bounded publisher responsibility, current state, bindings and evidence that counterparties can resolve again.

• RESPONSIBILITY CAN ANSWER

  Which organisation claims responsibility for publishing or operating this SDK identity?

• RESPONSIBILITY DOES NOT MEAN

  Every release, dependency, security property or third-party claim has been independently verified.

• PUBLISHER CHANGES

  A maintainer or publisher relationship can change while the canonical package identity remains stable where appropriate.

• PARENT CONTEXT

  Links the SDK Passport to the responsible organisation/Parent where present.

• EVIDENCE

  Supports bounded claims according to source, scope and freshness.

• RE-CHECK

  Resolve again when publisher responsibility matters to the decision.

• REPOSITORY

  Source repository or project reference where supported.

• PACKAGE REGISTRY

  Registry / namespace / package coordinate.

• RELEASE / VERSION

  Release-family or version reference where supported.

• DOCUMENTATION

  Official documentation or metadata surface where supported.

• PROVIDER / ECOSYSTEM

  Distribution provider or ecosystem-specific identifier as context.

• EVIDENCE LINK

  Reference that supports a bounded claim about the package identity.

• IDENTITY PERSISTS

  The ECZ-ID can remain stable across supported repository, registry and release changes when the underlying SDK/package object remains the same.

• CONTEXT CHANGES

  Published release 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 release binding or publisher context is still current because the ECZ-ID itself is unchanged.

• IDENTITY

  Which SDK/package object is this?

• RESPONSIBILITY

  Who claims publication/responsibility?

• LOCAL POLICY

  Is this package/version permitted in this environment?

• SECURITY CONTROLS

  Are signing, vulnerability, licence and runtime requirements satisfied?

• REPOSITORY MIGRATION

  Preserve package identity when source hosting moves.

• REGISTRY MIGRATION

  Keep the same ECZ-ID while supported registry/package coordinates change.

• RELEASE VERIFICATION

  Connect a stable package identity to current release/version context.

• ENTERPRISE DEPENDENCY REVIEW

  Give architecture/security teams a re-checkable identity anchor for an SDK.

• MACHINE CONSUMPTION

  Allow automation to resolve bounded package identity/context before dependency decisions.

• CROSS-PROVIDER DISTRIBUTION

  Treat provider-native package IDs as bindings rather than the authority root.

• BEFORE

  Consumers know the SDK by ECZ-ID plus repository, registry and release bindings.

• AFTER

  The SDK ECZ-ID remains stable; supported registry/documentation bindings and evidence are updated and Resolver reflects the current record.

• CONSUMER ACTION

  Re-resolve before adopting the new distribution location or release.

• SECURITY ACTION

  Validate package signatures, vulnerabilities, licence and local approval independently.

• STRONG FIT

  SDKs/packages distributed across repositories, registries, versions or providers where durable identity matters.

• SECURITY FIT

  Teams that need a stable object identity before applying separate software-supply-chain controls.

• DEVELOPER FIT

  Tooling that needs a machine-resolvable package identity independent of one package coordinate.

• LOWER-VALUE FIT

  Single-use or ephemeral package artifacts where persistent cross-context identity brings little benefit.

• If required proof is present and fresh → evaluate local package policy / proceed

• If absent, stale or mismatched → challenge, deny, pin or re-resolve

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

• IF REQUIRED PROOF IS ABSENT

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

• OBJECT

  SDK / software package / release family.

• PERSISTENT IDENTITY

  One canonical ECZ-ID can survive repository, registry and version changes where object continuity holds.

• RESPONSIBILITY

  Organisation/Parent and publisher context where present.

• BINDINGS

  Repository, registry, docs, release/version and provider references where supported.

• EVIDENCE + STATE

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

• BOUNDARY

  Not code safety, vulnerability-free status, build attestation, licence approval or execution permission.