Lightweight identity credentials for content compliance. Designed for cases where W3C VCs are too heavy and API keys are too simple.
The identity half of the .m3m3tic ecosystem. A .cr3st4n1 file
answers one question: is this actor who they claim to be, and how
much should you trust that claim?
cargo install cr3st4n1# Generate a signing key
cr3st4n1 key generate --output key.json
# Sign a credential
cr3st4n1 credential sign --input identity.cr3st4n1 --key key.json
# Inspect a credential (identity, trust, signature status, content hash)
cr3st4n1 credential inspect --input identity.cr3st4n1
# Inspect with inline signature verification
cr3st4n1 credential inspect --input identity.cr3st4n1 --key key.json
# Verify signature only
cr3st4n1 credential verify --input identity.cr3st4n1 --key key.json
# Content hash (actor_ref for .m3m3tic files)
cr3st4n1 hash --input identity.cr3st4n1credential inspect answers "what is this file?" in one command:
$ cr3st4n1 credential inspect --input case-studies/operator-alpha.cr3st4n1 --key bonfire-platform-key.json
Identity: Operator Alpha (human)
email: operator@example.com
org: Bonfire Terminal Inc.
Trust: Level 1 (email_verified)
providers: 1
device: none
chain:
-> bonfire-platform (email_verification, 2026-07-23)
Signature:
signer: bonfire-platform (Ed25519)
signed at: 2026-07-23T18:00:00Z
hash: ade88d3bdc325bc55e1931b7770b75b476eb820869be836abe62d6d950393c87
status: valid
Use --json for machine-readable output (credential verbatim + _inspect metadata block).
Use --key to verify the signature inline. Without --key, signature status shows present or absent.
Exit codes: 0 = success, 1 = parse/schema error, 2 = signature verification failed.
YAML files with Ed25519 signatures. Trust levels 0-5. Offline-verifiable. JSON Schema (Draft 2020-12) for validation.
cr3st4n1:
version: "1.0.0"
created_at: "2026-07-23T00:00:00Z"
identity:
type: "human"
display_name: "Alice"
email: "alice@example.com"
verification:
level: "email_verified"
providers:
- type: "platform_registration"
provider: "bonfire"
device:
binding_level: "none"
registered_at: "2026-07-23T00:00:00Z"
trust:
level: 1
credential_chain:
- issuer: "bonfire-platform"
issued_at: "2026-07-23T00:00:00Z"
method: "email_verification"
_signature:
signer: "bonfire-platform"
algorithm: "Ed25519"
signed_at: "2026-07-23T00:00:00Z"
signature: ""examples/minimal.cr3st4n1— Trust level 1, email verified humanexamples/full.cr3st4n1— Trust level 4, AI agent with TPM attestationcase-studies/operator-alpha.cr3st4n1— Real signed credential (see case study)
| Level | Name | Verification |
|---|---|---|
| 0 | Anonymous | None |
| 1 | Email verified | |
| 2 | Single-gate | One provider (e.g., contract signed) |
| 3 | Dual-gate | Two providers (e.g., HelloSign + Circle.so) |
| 4 | Gov ID | Government-issued identity document |
| 5 | Fully attested | Gov ID + TPM hardware attestation |
| Alternative | Why cr3st4n1 exists |
|---|---|
| W3C VCs (DIDKit, Aries) | Full VC stack is ~30 crates. cr3st4n1 is 1 crate, 4 source files. |
| API keys | No identity information, no trust levels, no offline verification. |
| JWTs | No schema validation, no selective disclosure path, no content-addressed DID. |
| OAuth tokens | Require online verification. cr3st4n1 verifies offline. |
| Command | Description |
|---|---|
key generate --output KEY |
Generate Ed25519 signing keypair |
key public --key KEY |
Extract public key from keypair |
credential validate --input FILE |
Validate against embedded JSON Schema |
credential sign --input FILE --key KEY |
Sign credential (validates schema first) |
credential verify --input FILE --key KEY |
Verify Ed25519 signature |
credential inspect --input FILE [--key KEY] [--json] |
Inspect credential: identity, trust, signature, hash |
hash --input FILE |
Print SHA-256 content hash (for actor_ref) |
All operations complete in under 100 microseconds on commodity hardware.
Run cargo bench for numbers on your machine.
Credentials can be verified in Python with one dependency (pynacl):
pip install pynacl
python examples/verify.py signed.cr3st4n1 <pubkey_base64>Cross-language verification is tested in CI. The Python verifier uses line-level string replacement to reproduce Rust's canonical form, avoiding serialization differences between serde_yaml and PyYAML.
See case-studies/bonfire-terminal-issuance.md for a real credential issued by Bonfire Terminal v2.7.309, signed and verified in both Rust and Python.
See SPEC.md for the full v1.0.0-rc.1 format specification.
# In a brand's .m3m3tic file
relationships:
- actor_ref: "sha256:ade88d3b..." # SHA-256 content hash of the .cr3st4n1 file
actor_name: "Operator Alpha"
type: "agency"
authority:
brand_voice: true
spend: trueOne actor, one credential. Multiple brands can reference it independently.
- m3m3tic — Brand identity + compliance policies
- did:m3m3tic — DID method specification
- bonfire-terminal — Desktop app + Rust daemon (issues credentials)
Apache 2.0