Skip to main content

Roadmap

Shipped is available in the current release. Planned is intended but not built. Parked is valid scope that has been deliberately deferred, with a recorded reason.

Nothing on this page that is unchecked is available

Unchecked items are not partially available, not behind a flag, and not in a preview. If a page in these docs describes a capability, it ships; if it appears here unchecked, it does not.

HelixID is pre-1.0. Package versions are independent 0.x releases, and security patches are provided for the latest minor only.

Phase 1 — Foundation​

  • Architecture decisions — DLT-agnostic core, VCs vs. simple signing, latency analysis
  • @helixid/sdk-js — wallet, VP build/verify, delegation, API client
  • @helixid/core — DID resolution, Ed25519, VP verification, canonical JSON
  • @helixid/mcp — MCP client helper and server middleware
  • @helixid/langchain — LangChain / LangGraph middleware
  • @helixid/cli — operator CLI
  • @helixid/widget — SP-side consent scope resolution and headless controller
  • did:key local mode
  • did:web hosted mode (default)
  • Bitstring Status List (StatusList2021) revocation
  • Session token bridge — VC → ephemeral JWT
  • Operator Console — agents, enrollment, audit trail
  • Two-issuer consent model — platform ceiling + SP-issued grant
  • Agent-to-agent sub-delegation with chain verification

did:hedera anchored mode​

  • @helixid/did-hedera resolver — read DID documents from a public mirror node
  • Planned Issuer-side DID_METHOD=hedera — .env.example currently accepts web and key only

Policy engine​

  • Parked OPA integration and a base Rego policy library

Parked because the core trust path is already enforced in code — VP signature, VC signature, expiry, revocation, vpId replay protection, and delegation constraints. OPA is a business-policy layer, not a crypto/trust layer, so it can wait for clearer service-owner policy requirements rather than bringing sidecar operations, policy authoring, and failure-mode design forward before they are needed. Constraints already agreed for when it lands are in Authorization & Scopes.

JSON-LD context hosting​

  • Parked Host the HelixID JSON-LD context and define its Helix-specific terms

Issued VCs reference a HelixID-specific context that is not yet hosted. Verification uses local canonical JSON signing and does not fetch it, so local and self-hosted flows work — but this must be resolved before HelixID can claim full public JSON-LD/VC ecosystem interoperability. See Verifiable Credentials.

Phase 2 — Framework Integrations & Scale​

  • Parked Python SDK (helix-sdk-py) — parked until the JS/TS SDK surface is stable enough to mirror without creating divergent crypto behaviour. Compatibility tests must prove Python-generated VPs verify through the same path as JS-generated ones.
  • Parked @helixid/crewai — CrewAI integration. Parked until the Python SDK exists; building it now would need either a temporary Python signing path or duplicated SDK behaviour.
  • Planned @helixid/n8n — n8n node
  • Planned Trust registry v1 — shared issuer vetting, so accepting a new organization's credentials is an O(1) lookup rather than a per-org allowlist entry

Storage and caching​

  • Parked Postgres storage adapter — SQLite remains the default path
  • Parked Redis / L2 shared cache — the L1 in-process memory cache is enabled by default and is not a blocker for current runs

Both are parked pending clearer storage/migration and shared-cache requirements. See Performance & Caching.

Phase 3 — Enterprise & Advanced​

  • Planned ZKP selective disclosure (ZK-SD-VCs) — prove a credential attribute without revealing every field. The architecture is designed to accommodate this; the implementation is a later phase.
  • Planned ABAC policy engine
  • Planned Credential monetization primitives
  • Planned Kubernetes admission controller
  • Planned HelixID Cloud — managed service, including the hosted trust registry

Nothing in the self-hosted stack depends on HelixID Cloud. The open-source path is not a limited edition of a paid product — see Self-Hosted vs Cloud.

How this list is maintained​

Architectural decisions, including the reasoning behind parking an item, are recorded in the code repository's append-only decision log. Parked items keep their acceptance criteria written down so that picking one up later does not mean re-deriving the constraints.

Requests and discussion: GitHub Discussions.