Provider neutrality

Bind. Integrate. Resolve. Interpret. Prove.

Bind

Attach an ECZ-ID to identities your ecosystem already issues: registries, origins, packages, workload identities.

Integrate

Sit beside your authentication, authorisation and transport. Never replace them.

Resolve

Give any relying party one public, live answer for who stands behind a machine.

Interpret

Say what a state means, and what it must not be read as.

Prove

Record what happened as evidence that can be re-checked later.

What stays yours

Your identity provider, your OAuth scopes, your API keys, your transport, your framework, your cloud workload identity and your data all stay exactly where they are. ECZ-ID does not run your agent, proxy your traffic, hold your keys or sign your releases.

Defined classes, not claimed integrations

The families contract names binding classes across many ecosystems: A2A cards and MCP Registry entries, OpenAPI descriptions and JWKS URIs, package registries and repository OIDC, AWS IAM roles, GCP and Entra workload identities, SPIFFE IDs, Kubernetes service accounts and OIDC issuers. A class being defined means ECZ-ID has a place to record that binding. It is not a claim of partnership, certification or a live integration with that provider.