6.1 KiB
Vocabulary crosswalk
Our words, the standard words, and which is which. Written so an assessor can follow their own vocabulary into this system, and so we can keep a term where ours is genuinely sharper without that being an obstacle.
This is the ordinary compliance practice of a mapping: NIST publishes the same thing between 800-171 and 800-53. The value is not in picking a winner. Picking one would be wrong anyway — XCCDF is configuration scanning, C2PA is media provenance, in-toto is software supply chain, and none was built for a P2P data mesh.
On sourcing. Rows marked ✓ were checked against the specification during this session. Rows marked ~ are from working knowledge and want confirming before they go in front of an assessor. A term cited wrongly is worse than a term not cited, because a citation reads as authority.
1. Where we already use the standard word
Nothing to do here. Listed so a reader can stop looking.
| ours | standard | source |
|---|---|---|
principal |
principal | Kerberos, AWS IAM, Java security, NIST RBAC ~ |
delegation |
delegation | NIST RBAC, OAuth 2.0 ~ |
scope |
scope | OAuth 2.0 ~ |
grant |
grant | OAuth 2.0, XACML ~ |
Tier::sql_verb() → SELECT/INSERT/UPDATE/DELETE |
the SQL verbs | ISO SQL ✓ |
canonical_json() |
JSON Canonicalization Scheme | RFC 8785 ✓ |
| Ed25519, SHA-256, SipHash-2-4 | same | RFC 8032, FIPS 180-4 ✓ |
2. Where we invented a word and a standard exists
This is the list that matters.
2.1 Stance — the verdict
Adopt the standard. XCCDF is NIST's own, it is what a SCAP-literate assessor reads, and our three values map exactly onto three of its nine.
| ours | XCCDF rule-result ✓ |
|---|---|
Clean |
pass |
Violated |
fail |
Unverifiable |
unknown |
XCCDF's full set is pass, fail, error, unknown, notapplicable,
notchecked, notselected, informational, fixed.
The one reservation. Unverifiable says why nothing is known —
the evidence could not be checked — where unknown covers that and
several other cases. Ours is more precise; theirs is recognisable. For a
verdict an outsider reads, recognisable wins.
Prior art worth knowing: OCSP answers the same shape with good /
revoked / unknown ~. Three values, and the third is "we cannot say"
— the same design decision, reached independently, which is a good sign
the three-value shape is right.
2.2 Annotation — a claim about a datum
| ours | C2PA ✓ | in-toto ✓ |
|---|---|---|
Annotation |
assertion — a statement the signer makes about the asset | predicate |
| the signed row carrying it | claim — the signed container grouping assertions | Statement (_type, subject, predicateType, predicate) |
ProofBundle |
manifest — assertions + claim + signature as one verifiable unit | — |
content_tag |
the asset | subject |
Keep ours, and say what it maps to. C2PA's assertion is the closest single word, and the C2PA shape is genuinely similar: individual statements, grouped and signed together. But their claim and manifest have media-provenance meanings that would mislead here, and adopting one word of a three-word system imports the confusion without the benefit.
The mapping is the deliverable, not a rename.
2.3 The hash names
| ours | standard | note |
|---|---|---|
row_hash |
Merkle leaf hash ~ | ours is a keyed MAC, theirs usually is not |
anchor_hash |
Signed Tree Head, RFC 6962 ~ | needs checking before it goes in a filing |
Do not rename. These are frozen byte shapes; the field names feed
hashed payloads, and renaming a key that feeds a hash silently breaks
every artifact already signed under the old spelling. See the lesson
freeze-tokens-for-hashed-keys.
2.4 Smaller ones
| ours | standard | verdict |
|---|---|---|
producer registry |
PKI issuer ~; C2PA claim generator ✓ | keep — ours is a registry of keys, not an issuer of certificates |
Tier |
NIST RBAC operation ~ | keep — ours is a damage taxonomy that happens to map 1:1 onto the SQL verbs, which "operation" does not convey |
content_tag |
in-toto subject ✓; content-addressing CID ~ | keep, map to subject |
3. Genuinely ours
No standard equivalent found. These are the ideas worth defending as novel rather than translating.
- chain-break-as-event. A monitored condition failing is recorded as a first-class row rather than raised as an error, so the violation is evidence rather than something a log swallowed.
- One chain per
(data, node). Nobody writes to anybody else's chain, so a node cannot forge a record it did not make, and the picture is recovered by merging rather than by agreeing. - Tier → RLS with no translation layer. The four tiers are the four SQL verbs, so a grant compiles to a row-level-security predicate directly. The translation layer is where an application's idea of a permission and the database's drift apart.
rows_valid/fully_signed/continuous/intact(). Four separate questions instead of one boolean, because "did the signatures check" and "was anything unsigned" and "was a break recorded" have different answers and different consequences.
4. What to do with this
| Rename now | Stance → XCCDF's pass / fail / unknown. Days old, one consumer, cheap. |
| Map, don't rename | Annotation, ProofBundle, content_tag, Tier, producer registry. Load-bearing across crates and, for some, already in a committed migration. |
| Never rename | row_hash, anchor_hash, and any other key feeding a hashed payload. |
| Defend as novel | section 3. |
Sources checked this session: NIST XCCDF 1.2 schema · OpenSCAP manual · C2PA specification · in-toto Statement layer