# OKF Attestation Binding Profile

**Version 0.1.0-draft.1 — 2026-08-05**
**Binds:** Google Open Knowledge Format (OKF) v0.2
**Publisher:** Rubric Protocol (rubric-protocol.com)
**Status:** Draft — pinned to OKF v0.2; will re-pin on OKF minor releases.

## 1. Purpose

OKF v0.2 defines trust vocabulary (`generated`, `verified`, `status`,
`stale_after`, `sources`) but all values are self-asserted plaintext.
This profile defines optional, backward-compatible extension frontmatter
that binds an OKF concept's content to an independently verifiable,
post-quantum-signed, ledger-anchored attestation. OKF v0.2 consumers
that do not understand this profile MUST preserve the extension key
(per OKF spec: unknown keys are preserved, never rejected).

## 2. Extension key

A bound concept carries one additional top-level frontmatter key:

~~~yaml
rubric_attestation:
  profile: "okf-binding/0.1"
  content_hash: "<hex SHA3-256, per section 3>"
  attestation_id: "<rubric attestation id>"
  anchor:
    network: "hedera-mainnet"
    hcs_topic: "0.0.10416909"
    hcs_seq: <int>
  key_id: "059e19c1-1173-4ca3-bc78-848fcef53be5"
  alg: "ML-DSA-65"
  signed_at: "<ISO 8601>"
  verify_url: "https://rubric-protocol.com/verify/<attestation_id>"
~~~

All fields REQUIRED except `anchor.hcs_seq` MAY be absent for ≤5 min
after write (async anchoring window).

## 3. Content hash (canonicalization)

Circularity rule: the hash covers the concept EXCLUDING the
`rubric_attestation` key itself.

~~~
canonical_bytes =
  JCS(frontmatter minus rubric_attestation)   # RFC 8785, YAML->JSON
  || 0x00
  || body_bytes                               # UTF-8, CRLF->LF, no trailing-space trim
content_hash = SHA3-256(canonical_bytes)
~~~

YAML->JSON mapping: YAML scalars map to JSON per YAML 1.2 Core Schema;
key order irrelevant (JCS sorts).

## 4. Leaf construction

Per-concept leaf, leafType `okf-concept-v1`:

~~~json
{
  "leafType": "okf-concept-v1",
  "bundle_id": "<producer-chosen stable bundle identifier>",
  "concept_id": "<OKF concept ID, e.g. tables/orders>",
  "okf_version": "0.2",
  "content_hash": "<hex>"
}
~~~

Leaves are batch-attested (Rubric tiered path), Merkle-aggregated
(SHA3-256), federation-signed (3-of-5 independent ML-DSA-65), and
HCS-anchored.

## 5. Relationship to OKF v0.2 trust fields

- A `verified` event whose actor also appears as the attestation
  producer is *cryptographically corroborated*; otherwise it remains
  self-asserted. This profile does not modify `verified` semantics.
- OKF "Attested Computation" (section 10) `attester` MAY reference a
  Rubric attestation ID; binding of computation I/O is out of scope
  for 0.1.

## 6. Verification procedure

1. Parse frontmatter; extract and remove `rubric_attestation`.
2. Recompute `content_hash` per section 3; compare.
3. Resolve `verify_url` (or verify offline against published federation
   keys + HCS mirror); require valid signature quorum + Merkle
   inclusion + anchor consistency.
4. Result tiers: `bound-verified` | `hash-mismatch` (content drifted
   after signing) | `unresolvable` (anchor/sig check unavailable).

Reference verifier: https://rubric-protocol.com/docs/verify-okf.py

## 7. Staleness interaction

`hash-mismatch` is orthogonal to OKF `stale_after`: a concept can be
fresh-but-tampered or stale-but-intact. Consumers SHOULD surface both.

## 8. IANA-style considerations

None. Extension key namespace `rubric_attestation` is claimed by this
profile; producers MUST NOT emit it without a resolvable attestation.