Repository navigation
[Impl] catalog_ref versions can't be checked: add an optional content digest #129
Description
What did you build?
An implementation that parses and validates OpenProposal proposals, line items and commitments end to end.
What you tried to express, and what happened
§ 2.2 says "A catalog entry MUST be immutable once referenced", and that at agreed every catalog_ref is replaced by its resolved value. A receiver has no way to check either. It can't confirm that @3 resolves to the same content today as at discovery, and once the reference is replaced, the agreed record can't show what the reference pointed to. #63's record_digest would make the agreed record tamper-evident. It doesn't let a receiver check a reference against the catalog entry itself.
What you did instead
Recorded my own content hash of each resolved entry at discovery, and refused to commit if a re-resolution differed.
Suggested resolution: if catalogs stay in 3.0 (OQ-2, #3), add an optional content digest alongside the version, for example …@3#sha256:…, and keep the original reference next to the resolved value in the agreed record.
Fields involved
catalog_ref (§ 2.2)
How blocking was it?
Workaround required, but it works
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This contains no confidential or commercially sensitive information — no real rate cards, deal terms, client names or inventory data.
Activity
peterduhon commentedon Nov 12, 2026
Supporting this, with one convergence note from the #116 thread: the diligence digest there landed on the Digest string form (§2.2, sha256: + 64 hex, per #137) rather than an { alg, value } object, with the version-suffixed ref as the unsigned fallback. Whichever form #129 adopts, catalog_ref and diligence_ref should converge on the same digest representation, with the version-suffixed reference remaining the unsigned fallback. One digest mechanism across reference types (#157).
Pre-flight log:
Stale one-liner retired — it recommended the { alg, value } shape, contradicting the #116 acceptance (Digest string, per #137) posted within 24 hours. Same failure class as the "origin semantics" slip: memory fills in superseded values. The corrected text mentions { alg, value } only as the form #116 rejected — stated as fact, not endorsed.
Consistent with the #116 acceptance on every particular: Digest string form, §2.2, sha256: + 64 hex, per #137, version-suffixed ref as the unsigned fallback.
Takes no side on #129's open form question ("whichever way #129 resolves"); asks only for one digest mechanism across reference types (#157).