Metadata-Version: 2.4
Name: zeromodel-trust
Version: 1.2.0
Summary: ZeroModel artifact trust, authenticity, and deployment-scope authorization kernel
Author-email: Ernan Hughes <ernanhughes@gmail.com>
License: MIT
Project-URL: Homepage, https://github.com/ernanhughes/zeromodel
Project-URL: Repository, https://github.com/ernanhughes/zeromodel
Project-URL: Documentation, https://ernanhughes.github.io/zeromodel/
Keywords: visual-policy-map,vpm,artifact-trust,signature-verification,deployment-authorization
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Science/Research
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: numpy>=1.23
Requires-Dist: cryptography>=41
Requires-Dist: zeromodel==1.2.0
Requires-Dist: zeromodel-artifacts==1.2.0

# zeromodel-trust

Artifact trust, authenticity, and deployment-scope authorization kernel for
the ZeroModel workspace.

## Claims boundary

The supported claim is: ZeroModel can verify the integrity, signature, and
declared deployment authorization of an identified artifact under a bounded
trust policy.

This package does **not** claim: secure hardware, remote attestation, PKI
deployment, regulatory certification, supply-chain security closure, or
tamper-proof storage.

## What this checks, as separate decisions

- **Integrity** - do the canonical bytes match the declared artifact digest?
- **Authenticity** - was the artifact's authorization manifest signed by a
  key belonging to the declared signer?
- **Trust** - is that signer accepted under the active trust policy?
- **Authorization** - is this signer permitted to authorize this artifact
  kind for this deployment scope?
- **Freshness / rollback** - is the artifact within its validity window, at
  an acceptable policy epoch, and not revoked?

Each of these is preserved as its own boolean on `TrustDecisionDTO` - never
collapsed into a single opaque pass/fail.

## Cryptography

Ed25519 via the `cryptography` package (a standard, audited library) - no
custom cryptographic primitives. The signature covers a canonical digest of
the artifact's authorization manifest (artifact digest, artifact kind,
deployment scope, policy epoch, validity window, issuer identity) - never
just rendered pixels, a filename, or an embedded checksum string.

Private-key generation/signing helpers in `zeromodel.trust.crypto` exist for
tests and explicit authoring workflows only. Production loading only ever
verifies; it never signs, and no private key material is ever written to a
fixture, report, or source-controlled file.

## Signature-envelope identity

`TrustDecisionDTO.signature_envelope_id` is a content-derived digest
(`compute_signature_envelope_id`, binding `authorization_id`, `signer_id`,
`signature_hex`, `key_algorithm`, and `spec_version`) - never the raw
signature hex stored under an identity-shaped field name.
`SignatureEnvelopeDTO.__post_init__` rejects any `spec_version` other than
the current supported one (multi-version verification is not deliberately
implemented), so the envelope identity always reflects the version that
was actually verified. Signature-envelope revocation
(`RevocationRecordDTO(target_kind="signature_envelope", ...)`) targets this
same computed identity, so a decision's recorded evidence and the
revocation check that can block it always agree on what "this envelope"
means.
