open-standards/joule-code/joule-code-rs/crates/joule-code-identity/examples
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science caaabc8da1 joule-code-identity: a Roster — resolve did:key → {label, kind} for audit
An audit reading raw signing keys is correct but unreadable. The Roster maps
known principals' keys to their labels and kinds, so a record renders "alice
(human)" / "granite-reviewer (agent)" instead of a bare did:key — while an
unknown signer stays fully traced by its did:key, just unnamed.

It is a NAMING layer, not a TRUST layer, and the docs say so plainly: the key
is the authoritative trace; a roster entry is a claim by whoever maintains the
file that a key belongs to a label — asserted, not cryptographically proven
(the status of /etc/hosts or SSH known_hosts). Resolution never changes what
an artifact verifies; it only renders who a verified key is called. register()
dedupes on key (the maintainer's latest naming wins); resolve / resolve_did /
describe read it; load_or_default / save persist it as plain JSON (public keys
and labels only — no secrets). Plus a free did_key(&[u8;32]) so any artifact
field can be rendered without constructing a Principal.

Runnable: `cargo run -p joule-code-identity --example audit` resolves an
author and two reviewer keys to names, and shows an unknown signer still
traced. 6 tests; example + clippy clean.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-11 19:27:37 -04:00
..
audit.rs joule-code-identity: a Roster — resolve did:key → {label, kind} for audit 2026-06-11 19:27:37 -04:00