feat: Decision-Rights Matrix and Constraint Catalog binding in ZeroID tokens

[rsharath]

Summary

ZeroID tokens currently carry identity and delegation claims but have no binding to the governance artifacts that authorize what a delegation is permitted to do. The proposed NHI IAM standard (and emerging multi-cloud NHI governance frameworks) introduce two mandatory artifacts:

• Decision-Rights Matrix (DRM) — a version-controlled, human-maintained document that enumerates which agents may delegate to which other agents, over which resources, and under what conditions. The DRM is treated as a cryptographically bound artifact: its SHA-256 hash is embedded in every delegation credential so that the enforcement point can verify the credential was issued under the currently-active governance policy.
• Constraint Catalog — a machine-readable, versioned policy document (analogous to Cedar policy sets) that defines hard bounds on what any agent may do. It is re-signed every 24 hours and its hash is similarly bound into tokens.

Neither artifact exists in ZeroID today. Cedar policies enforce constraints at evaluation time, but there is no cryptographic link between a token and the policy version that was in effect when the token was issued.

Problem

Without DRM/Constraint Catalog binding:

1. A token issued under a permissive policy version remains valid even after the policy is tightened — there is no mechanism to distinguish "issued under old policy" from "issued under current policy" without full token revocation.
2. Delegation tokens cannot prove which governance artifact authorized the delegation, making post-hoc audit incomplete: you can see that agent-B was delegated from agent-A, but not which DRM version authorized that delegation relationship.
3. Compliance frameworks (SOC 2, ISO 42001, EU AI Act) increasingly require evidence that agent actions were bounded by a specific, auditable policy version — not just that a policy existed.

Proposed Implementation

1. Decision-Rights Matrix artifact

• Define a DRM schema (JSON or YAML) that enumerates:
  • allowed_delegations: [{from: <SPIFFE URI pattern>, to: <SPIFFE URI pattern>, resources: [...], conditions: {...}}]
  • version: semver string
  • effective_at: ISO 8601 timestamp
  • expires_at: ISO 8601 timestamp
• Store DRM documents in a versioned store (S3/GCS with object versioning, or a dedicated key-value store with immutable writes).
• Compute SHA-256(canonical_json(drm_document)) as the binding hash.

2. Constraint Catalog artifact

• The Constraint Catalog is the compiled, signed representation of the active Cedar policy set for a project.
• On every Cedar policy publish, compute SHA-256(canonical_cedar_policy_set) and sign with the ZeroID signing key.
• Re-sign every 24 hours to prove liveness (defense against stale catalog replay).
• Store the signed catalog hash in the ZeroID metadata store, keyed by (account_id, project_id, effective_at).

3. Token binding

Add two new optional claims to ZeroID JWTs (present only for delegation tokens issued via token_exchange and authorization_code grants):

{
  "drm_version": "1.4.2",
  "drm_hash": "sha256:a3f1...",
  "constraint_catalog_version": "2026-04-07T00:00:00Z",
  "constraint_catalog_hash": "sha256:7bc2..."
}

• Token issuance MUST fail if the requested delegation is not authorized by the current DRM.
• Token issuance MUST record the active constraint catalog hash at time of issuance.
• Introspection response (/oauth2/introspect) MUST include these claims so enforcement points can verify freshness.

4. CAE signal: policy drift

Add a new CAE signal type policy_drift that is emitted when:

• The active DRM version changes and outstanding tokens reference an older drm_hash
• The active constraint catalog is re-signed and the new hash differs from tokens' constraint_catalog_hash

Receiving a policy_drift signal should trigger token re-evaluation (not necessarily immediate revocation, but re-issuance with updated hashes on next use).

5. Audit trail

The Governance & Reporting module should surface:

• "Token issued under DRM version X" in the audit archive
• DRM version history with effective periods
• Constraint Catalog version history with signing timestamps

Acceptance Criteria

• DRM schema defined and documented
• DRM storage and versioning implemented
• Constraint Catalog hash computed and stored on each Cedar policy publish
• drm_hash and constraint_catalog_hash claims added to delegation token issuance
• Token issuance enforces DRM authorization check
• Introspection includes DRM/Constraint Catalog claims
• policy_drift CAE signal implemented
• Audit archive records DRM version per token issuance event
• Documentation: Credential Policies guide updated; new Governance & Reporting section for DRM/Catalog history

References

• NHI IAM proposed standard, Directives 6–7 (Decision-Rights Matrix, Constraint Catalog)
• ZeroID token flows: token_exchange (RFC 8693), delegation chain claims (act, delegation_depth)
• Cedar policy evaluation in Shield
• CAE signals: zeroid/internal/cae/signals.go