Skip to content
sovm.io

Manifest profile

1. The blob field set

Section titled “1. The blob field set”

A blob object’s semantic description is the same immutable producer-signed ObjectManifest defined in SOP/1 section 12.2, with the tabular fields replaced by blob fields:

manifest_version
mesh_id
object_kind = blob
storage_id
asset_id
asset_table
content_type
plaintext_size
exact_byte_size
encryption_profile = SOP-BLOB-1
producer_site_id
producer_mls_epoch
created_hlc
key_ref
derived_from?
derivative_kind?
supersedes[]

Field meanings:

  • asset_id — the stable identity of the logical asset this object belongs to: 16 random bytes, minted when the asset first enters the mesh. The original and all its derivatives carry the same asset_id. It is the join key between the blob plane and the metadata tables, and the identity that deletion tombstones (lifecycle).
  • asset_table — the schema-qualified name of the APPEND_DELETE table that governs this asset’s lifecycle (assets and metadata). Naming the lifecycle authority in the immutable manifest means a garbage collector can determine eligibility without guessing which table’s tombstones apply.
  • content_type — the asset’s media type (for a derivative, the derivative’s own type, e.g. image/jpeg for a video’s poster frame). Like all manifest fields it is encrypted catalog state (section 12.3); it is exactly as safe here as pruning statistics are for tables.
  • plaintext_size — the unpadded plaintext length in bytes; the authoritative truncation boundary for padded output (format, section 4).
  • exact_byte_size — the exact encrypted object length, as in SOP/1; the padded size is what untrusted storage observes.
  • encryption_profile — the object format identifier. This extension defines only SOP-BLOB-1; an unknown profile fails closed.
  • key_ref — the same opaque random 16 bytes written as the object’s cleartext trailer (format, section 2).
  • derived_from — for a derivative, the storage_id of the object it was computed from (usually the original; a chain is permitted, e.g. a poster frame derived from a transcode).
  • derivative_kind — a short application-scoped string naming the derivative’s role: thumbnail, poster, transcode, preview. Present if and only if derived_from is present.
  • supersedes[] — used only for derivative regeneration (lifecycle, section 2). An original blob object MUST NOT supersede anything.

Dropped relative to the tabular profile: table_schema, table_name, schema_fingerprint, row_count, partition_values, pruning_statistics, and row_identity_filter_ref — a blob has no rows to prune. Object selection happens by querying the metadata tables for storage_ids, which is the tabular plane’s existing job.

2. Signing and hashing

Section titled “2. Signing and hashing”

Unchanged from SOP/1 section 12.3: the manifest is deterministic CBOR under COSE_Sign1 with a key bound to the producer’s host identity; object_manifest_hash is BLAKE3 over the exact signed bytes; the profile’s binding rules cover manifest_version, mesh_id, producer_site_id, storage_id and object_kind, which is what makes the blob kind non-substitutable for a tabular kind.

3. Acceptance

Section titled “3. Acceptance”

Acceptance of a blob catalog entry is the same two-part rule as for any object (section 12.3): a valid producer manifest whose storage_id matches the bytes, and a valid applicable AccessRecord whose object_manifest_hash matches the exact signed manifest and whose issuer was authorized for the domain.

Two additional checks apply to the blob kind:

  1. object_kind = blob REQUIRES encryption_profile = SOP-BLOB-1 (or a later registered profile). A blob manifest naming an unknown profile, or a tabular manifest naming a blob profile, MUST be rejected.
  2. If derived_from is present, the referenced storage_id MUST have (or have had) a valid manifest with the same asset_id. A derivative may arrive before its source object’s bytes — that is the ordinary pending_bytes state of section 13.2 — but a derivative claiming a source with a different asset_id is invalid.

4. Keys and access records

Section titled “4. Keys and access records”

There is nothing blob-specific to specify, which is the point:

  • fresh random per-object DEK (section 7.4);
  • the DEK travels only inside a COSE AccessRecord encrypted under the current domain KEK generation (section 7.5);
  • rewrapping on KEK rotation replaces the access record, never the object bytes, subject to the entitlement rule (section 7.6);
  • historical access modes (FORWARD_ONLY, FULL_HISTORY, BOUNDED_HISTORY) apply to blob objects exactly as to tabular ones (section 8).

Because each derivative is an independent object with its own DEK and access records, a derivative MAY be granted into a different cryptographic domain than its original, subject to the same entitlement checks — the property that lets a low-trust display device hold thumbnails without holding originals (assets, section 4).