CBOR-CORE-LD v0.1.0

Status: Draft Encodes: CORE-LD v0.1.0 (foundational profile) Constitutional dependencies: URS v0.1.0 → CORE-LD v0.1.0 Spec family: Encoding Binding (CCA Framework §3; CORE-LD §6.2 — Adding an encoding binding) Encoding rule: CORE-LD + CBOR Canonical @context: https://specs.initialcore.net/ns/core-ld.jsonld Media types: application/cbor (canonical), application/ld+cbor (linked-data view)

1. Preamble

CBOR-CORE-LD is the encoding binding that serializes the CORE-LD abstract representation as deterministic CBOR (RFC 8949). Per CORE-LD §1.1, it sits at the syntax-specific layer of the dimensional architecture, alongside JSON-CORE-LD:

Reality → USC → URS → CORE-LD → [functional profiles] → [encoding bindings] → CodeLabs → CoreFab → studio
                                  Foundational          Role-specific         Syntax-specific

What CBOR-CORE-LD is:

• A deterministic, lossless mapping between the CORE-LD abstract representation and CBOR bytes
• The binary companion of JSON-CORE-LD — a mechanical translation: every term, structural rule, and framing step maps 1:1 to CBOR data items; no new semantics
• The wire/storage/signing encoding of the family — the form whose bytes are stable under hashing and linked data signatures (ICore doctrine: CBOR-LD for machines, JSON-LD for humans)

What CBOR-CORE-LD is not:

• Not a functional profile — it adds no semantics; it preserves CORE-LD semantics exactly
• Not an addressing mode — content addressing (DAG) composes with it via URS Canonicalization (DAG addressing mode), it does not define it
• Not a new data model — the URS/CORE-LD data model is the only authority; this spec only fixes byte representation

Composition rule (per CORE-LD §6.2):

CBOR-CORE-LD = CORE-LD + CBOR encoding
CBOR-[PROFILE]-LD = CORE-LD + [PROFILE] + CBOR encoding   (multi-profile binding, §8)

A conforming CBOR-CORE-LD implementation MUST preserve all 23 CORE-LD invariants (I1–I23) in the encoding, MUST define a deterministic lossless mapping between the abstract representation and CBOR bytes, and MUST round-trip any valid CORE-LD representation without loss of identity (L1/L2/L3 per CORE-LD §3.1). Both CORE-LD bindings encode the same abstract representation: JSON-CORE-LD and CBOR-CORE-LD are bidirectionally convertible without loss (§7).

Relation to earlier codecs: CBOR-CORE-LD v0.1.0 subsumes DAG-CBOR-LD v0.1.0 (the pre-CORE-LD CBOR codec draft). Its integer-key table (keys 0–23), deterministic encoding rules, and translation tables are inherited and aligned to the CORE-LD frame; DAG-CBOR-LD remains on record as the historical draft. The framing algorithm (§4) and deterministic CBOR rules (§5) here are the live versions.

2. CBOR Value Model

The CORE-LD representation kinds map to CBOR data items as follows. Every mapping is total and invertible on valid CORE-LD frames.

2.1 Scalar translation (JSON-CORE-LD §2 ↔ CBOR)

2.2 Native byte strings

CBOR byte strings (major 2) carry binary data exactly — no base64 expansion. JSON-CORE-LD represents binary as base64url text (a documented lossy encoding, JSON-CORE-LD §7); CBOR-CORE-LD is the exact form. Translation: on JSON→CBOR, base64url text is NOT auto-converted (it is ordinary text); on CBOR→JSON, byte strings decode to base64url text (the JSON binding's lossy form) — see §7.4.

3. Term Mapping and @context

3.1 Context requirement

Every CBOR-CORE-LD document MUST declare @context resolving to the CORE-LD canonical context (CORE-LD §8), either as a single text IRI:

{"@context": "https://specs.initialcore.net/ns/core-ld.jsonld"}

or, for multi-profile bindings, as an ordered array of text IRIs (§8). The context rules are identical to JSON-CORE-LD §3.1.

3.2 Keyword usage

Identical to JSON-CORE-LD §3.2: @context mandatory on the document, never on nested entities; @id carries entity/link/group identity (IRI or _: blank node, duplicates prohibited — I3); @type carries the entity kind drawn from {Entity, Property, Identifier, Link, Group} or a registered extension (I1).

3.3 Defined-term rule

Identical to JSON-CORE-LD §3.3: a property name is valid iff it is (1) a term defined in the active @context, (2) a compact IRI with a defined prefix, or (3) an absolute IRI. The conformance suite enforces this against the document's declared @context chain — the CBOR encoding does not relax the rule.

3.4 Integer key optimisation

CBOR permits integer map keys (major 0), which are dramatically more compact than text keys. CBOR-CORE-LD defines a fixed term→key registry (the canonical compact form):

Keys 0–23 are inherited verbatim from the historical DAG-CBOR-LD draft; keys 24–29 are added for the CORE-LD frame (mandatory @context, the links container, the identifier object, delegation metadata, and description). Profile terms (e.g., intent, storeType, jurisdiction) are NOT in the core registry and use full text keys — the registry is core-only by design.

A conforming implementation SHALL accept both integer-keyed and text-keyed maps on decode, and SHALL use integer keys for registered terms on canonical encode. The @key alias mapping in the canonical @context document records the registry:

{
  "@context": {
    "urs": "https://specs.initialcore.net/ns/urs#",
    "kind": {"@id": "urs:kind", "@key": 0},
    "@id": {"@key": 1},
    "@type": {"@key": 2},
    "value": {"@id": "urs:value", "@key": 3},
    "name": {"@id": "urs:name", "@key": 4},
    "target": {"@id": "urs:target", "@key": 5},
    "source": {"@id": "urs:source", "@key": 6},
    "linkType": {"@id": "urs:linkType", "@key": 7},
    "members": {"@id": "urs:members", "@key": 8},
    "entries": {"@id": "urs:entries", "@key": 9},
    "groupVariant": {"@id": "urs:groupVariant", "@key": 10},
    "isConstitutional": {"@id": "urs:isConstitutional", "@key": 11, "@type": "xsd:boolean"},
    "scope": {"@id": "urs:scope", "@key": 12},
    "Representer": {"@id": "urs:Representer", "@key": 13},
    "Timestamp": {"@id": "urs:Timestamp", "@key": 14, "@type": "xsd:dateTime"},
    "Authority": {"@id": "urs:Authority", "@key": 15},
    "authorityType": {"@id": "urs:authorityType", "@key": 16},
    "RepresentationContext": {"@id": "urs:RepresentationContext", "@key": 17},
    "PriorState": {"@id": "urs:PriorState", "@key": 18},
    "Provenance": {"@id": "urs:Provenance", "@key": 19},
    "provenance": {"@id": "urs:provenance", "@key": 20},
    "canonicalHash": {"@id": "urs:canonicalHash", "@key": 21},
    "grantedBy": {"@id": "urs:grantedBy", "@key": 22},
    "role": {"@id": "urs:role", "@key": 23},
    "@context": {"@key": 24},
    "links": {"@id": "urs:links", "@key": 25},
    "description": {"@id": "schema:description", "@key": 26},
    "identifier": {"@id": "urs:identifier", "@key": 27},
    "mayDelegate": {"@id": "urs:mayDelegate", "@key": 28},
    "delegationDepth": {"@id": "urs:delegationDepth", "@key": 29}
  }
}

4. Framing

CBOR-CORE-LD applies the CORE-LD frame in the same 7 steps as JSON-CORE-LD §4, with purely mechanical encoding differences:

1. Extract root — same (I11) 2. Assign @id — same; _: blank nodes for local identifiers 3. Embed properties — same structure, CBOR-encoded 4. Frame links — same keys, CBOR-encoded 5. Frame groups — members array (Set/Sequence), entries map (Map); no JSON-LD @list/@set wrappers in canonical form — tags 268/269 are accepted on decode for generic CBOR-LD interoperability but MUST NOT be emitted (JSON-CORE-LD emits plain containers; mechanical consistency) 6. Canonical ordering — map keys sorted per §5.1; arrays keep semantic order 7. Attach provenance — same (I16–I20 inheritance per CORE-LD §4.3)

5. Deterministic Serialization

5.1 Deterministic CBOR rules

The canonical CBOR-CORE-LD byte form follows RFC 8949 §4.2.1 (Core Deterministic Encoding Requirements), restricted to the value model of §2:

1. Integer encoding — integers encoded in the smallest length that fits the value range; unsigned values never use the negative major type. 2. Map key ordering — keys sorted length-first, then bytewise: shorter key encodings precede longer ones; equal-length encodings compare bytewise (RFC 8949 §4.2.1). 3. Text encoding — UTF-8, normalized to NFC before encoding. 4. Floats — IEEE 754 double (0xFB, 8 bytes big-endian); a float with integral value in range is NOT re-encoded as an integer (JSON-CORE-LD keeps numeric type from the source document). 5. Simple values — false, true, null use their single-byte forms 0xF4, 0xF5, 0xF6. 6. Indefinite-length items — prohibited. All maps, arrays, and text/byte strings use definite-length encoding. 7. Tags — MUST NOT be emitted beyond the registry (§2, §4); tags 268/269 accepted on decode only. 8. Whitespace — CBOR is binary; no padding or formatting bytes.

5.2 Canonical hash

• L2 content hash (CORE-LD §3.1): SHA-256 over the canonical CBOR of the framed document with `@context` and all `provenance` maps removed — identifiers and properties only. Multihash-wrapped (`0x12 0x20`), multibase `z`-prefixed (base58btc), per URS Canonicalization. Example (§9.1): `zQmWL9WCfiN9XRth8VKXdY3FB4BSNNu4VJZ99xuLjchyTXC`.
• L3 constitutional hash: SHA-256 over the full canonical CBOR including provenance — same algorithm, provenance included.
• Determinism: the same abstract representation always yields identical bytes (I21), so identical L2/L3 hashes.

Binding-level hashes: the L2/L3 hashes above are computed over this binding's canonical serialization — they are stable and reproducible, and may differ numerically from JSON-CORE-LD's L2/L3 hashes of the same representation (different byte forms, same structural identity; URS Canonicalization §1.2). The canonicalization-level CHash (URS Canonicalization §3.3) is computed over the URS Canonical Binary; the relationship is fixed by invariant C6 of that specification. The DAG addresses shown in §9 are block-derived (dag-cbor CID semantics over the canonical CBOR of the framed document as encoded — _: labels included); label-stable addressing is provided at the canonicalization level after §2.4 relabeling (URS Canonicalization §5.3 property 2).

6. Invariant Preservation

Every CORE-LD invariant is preserved by construction of the encoding. The conformance suite validates them on the decoded JSON-CORE-LD form (JSON-CORE-LD §6), which the CBOR form must round-trip exactly.

No CBOR encoding choice may weaken a check: e.g., I14 (local identifiers use _:) is enforced on the @id text itself, not on any container.

7. Round-Trip Transformation

7.1 The full cycle

CORE-LD abstract representation
  → JSON-CORE-LD frame (JSON-CORE-LD §4) → canonical JSON (JSON-CORE-LD §5.1)
  → CBOR-CORE-LD translation (§2, §4) → canonical CBOR bytes (§5.1)
    → decode CBOR (§7.3) → JSON-CORE-LD document
      → unframe → CORE-LD abstract representation

7.2 JSON → CBOR translation rules

7.3 CBOR → JSON translation rules

7.4 Round-trip invariants (RT)

Documented lossy encodings (inherited from JSON-CORE-LD §7, extended): byte strings → base64url text on decode (opaque, content-address changes); identifierless entities → generated blank nodes (labels unstable across documents); deep nesting beyond implementation limits → parse failure, never silent truncation. Unknown integer map keys, trailing bytes, and non-deterministic inputs (duplicate keys, indefinite-length items, non-minimal integers) MUST be rejected.

8. Multi-Profile Binding

Encoding bindings compose with functional profiles. A CBOR-encoded profile document (e.g., CBOR-INPUT-LD) is a CBOR-CORE-LD document that additionally satisfies the profile's invariants.

Binding rule (per CORE-LD §6.2, item 2):

CBOR-[PROFILE]-LD encodes CORE-LD + [PROFILE]

1. @context is the ordered array [core-ld.jsonld, <profile>-ld.jsonld]. 2. All CORE-LD invariants apply unchanged (profiles only add, never relax — CORE-LD §6.1). 3. Profile invariants (I-INPUT-, I-MEM-, I-POL-, I-TRUST-) are validated on the decoded form by the profile conformance extensions (profile_conformance.py). 4. The deterministic serialization rules (§5) are identical; profile documents hash deterministically the same way. 5. Profile terms are not in the integer-key registry (§3.4) — they use text keys.

Binding matrix (v0.1.0 family):

9. Examples

All hex dumps below are actual encoder output (cbor_core_ld.py), not hand-constructed. Each example mirrors its JSON-CORE-LD §9 counterpart byte-for-byte through the translation rules.

9.1 Minimal entity (JSON 281 B → CBOR 152 B, 54.1%)

a5                                  # map(5)
  01                                # key 1  (@id)
  64 5f 3a 65 31                    # text(4) "_:e1"
  02                                # key 2  (@type)
  66 45 6e 74 69 74 79              # text(6) "Entity"
  04                                # key 4  (name)
  67 4d 69 6e 69 6d 61 6c           # text(7) "Minimal"
  14                                # key 20 (provenance)
  a4                                # map(4)
    0d 6f 64 69 64 3a 69 63 6f 72 65 3a 61 64 6d 69 6e   # key 13 (Representer): text(15) "did:icore:admin"
    0e 74 32 30 32 36 2d 30 37 2d 33 31 54 30 30 3a 30 30 3a 30 30 5a  # key 14 (Timestamp): text(20) "2026-07-31T00:00:00Z"
    0f a1 10 68 69 6e 68 65 72 65 6e 74   # key 15 (Authority): map(1) { key 16 (authorityType): text(7) "inherent" }
    11 76 75 72 6e 3a 69 63 6f 72 65 3a 63 6f 6e 74 65 78 74 3a 6d 61 69 6e  # key 17 (RepresentationContext): text(22) "urn:icore:context:main"
  18 18                                # key 24 (@context)
  78 2f 68 74 74 70 73 3a 2f 2f 73 70 65 63 73 2e 69 6e 69 74 69 61 6c 63 6f 72 65 2e 6e 65 74 2f 6e 73 2f 63 6f 72 65 2d 6c 64 2e 6a 73 6f 6e 6c 64  # text(47) "https://specs.initialcore.net/ns/core-ld.jsonld"

Note the canonical key order: 01 < 02 < 04 < 14 < 18 18 — length-first, then bytewise (§5.1 rule 2).

L2: zQmWL9WCfiN9XRth8VKXdY3FB4BSNNu4VJZ99xuLjchyTXC DAG address (dag-cbor): zCHNJiSL4dYYVoA9K3Hu1CTb4H1DQe5XiNmuPfPdvfMoomy6W

9.2 Constitutional entity with provenance (JSON 398 B → CBOR 210 B, 52.8%)

0000  a6 01 6f 64 69 64 3a 69 63 6f 72 65 3a 61 64 6d   ..odid:icore:adm
0010  69 6e 02 66 45 6e 74 69 74 79 04 65 41 64 6d 69   in.fEntity.eAdmi
0020  6e 14 a4 0d 6e 64 69 64 3a 69 63 6f 72 65 3a 72   n...ndid:icore:r
0030  6f 6f 74 0e 74 32 30 32 36 2d 30 37 2d 33 31 54   oot.t2026-07-31T
0040  30 30 3a 30 30 3a 30 30 5a 0f a1 10 68 69 6e 68   00:00:00Z...hinh
0050  65 72 65 6e 74 11 76 75 72 6e 3a 69 63 6f 72 65   erent.vurn:icore
0060  3a 63 6f 6e 74 65 78 74 3a 6d 61 69 6e 18 18 78   :context:main..x
0070  2f 68 74 74 70 73 3a 2f 2f 73 70 65 63 73 2e 69   /https://specs.i
0080  6e 69 74 69 61 6c 63 6f 72 65 2e 6e 65 74 2f 6e   nitialcore.net/n
0090  73 2f 63 6f 72 65 2d 6c 64 2e 6a 73 6f 6e 6c 64   s/core-ld.jsonld
00a0  18 1b a4 01 6f 64 69 64 3a 69 63 6f 72 65 3a 61   ....odid:icore:a
00b0  64 6d 69 6e 02 6a 49 64 65 6e 74 69 66 69 65 72   dmin.jIdentifier
00c0  0b f5 0c 6e 63 6f 6e 73 74 69 74 75 74 69 6f 6e   ...nconstitution
00d0  61 6c                                             al

L2: zQmRjqNmDeP675FcMwoVZMJ6reD6QrJ2Px9V9qw6x4FwoYU DAG address (dag-cbor): zCHNJdr1wC6UWjjnfxXMVAPQK8goSJ817LgYz1PWxRaFMkK7n

9.3 Link (JSON 425 B → CBOR 221 B, 52.0%)

0000  a6 01 66 5f 3a 72 6f 6f 74 02 66 45 6e 74 69 74   ..f_:root.fEntit
0010  79 14 a4 0d 6f 64 69 64 3a 69 63 6f 72 65 3a 61   y...odid:icore:a
0020  64 6d 69 6e 0e 74 32 30 32 36 2d 30 37 2d 33 31   dmin.t2026-07-31
0030  54 30 30 3a 30 30 3a 30 30 5a 0f a1 10 68 69 6e   T00:00:00Z...hin
0040  68 65 72 65 6e 74 11 76 75 72 6e 3a 69 63 6f 72   herent.vurn:icor
0050  65 3a 63 6f 6e 74 65 78 74 3a 6d 61 69 6e 18 18   e:context:main..
0060  78 2f 68 74 74 70 73 3a 2f 2f 73 70 65 63 73 2e   x/https://specs.
0070  69 6e 69 74 69 61 6c 63 6f 72 65 2e 6e 65 74 2f   initialcore.net/
0080  6e 73 2f 63 6f 72 65 2d 6c 64 2e 6a 73 6f 6e 6c   ns/core-ld.jsonl
0090  64 18 19 81 a5 01 64 5f 3a 6c 31 02 64 4c 69 6e   d.....d_:l1.dLin
00a0  6b 05 67 5f 3a 63 68 69 6c 64 06 66 5f 3a 72 6f   k.g_:child.f_:ro
00b0  6f 74 07 68 63 6f 6e 74 61 69 6e 73 67 5f 3a 63   ot.hcontainsg_:c
00c0  68 69 6c 64 a3 01 67 5f 3a 63 68 69 6c 64 02 66   hild..g_:child.f
00d0  45 6e 74 69 74 79 04 65 63 68 69 6c 64            Entity.echild

L2: zQmcBfAomS2JH9ERmbaRMxa6WtX4EpvEAX3dXSytUZrLhGk DAG address (dag-cbor): zCHNJpHqjEeG9wuremw1G6C1b8M3kFwyjYT7t9m81D6kx9Cr4

9.4 Group (Sequence) (JSON 366 B → CBOR 185 B, 50.5%)

0000  a6 01 65 5f 3a 73 65 71 02 65 47 72 6f 75 70 08   ..e_:seq.eGroup.
0010  82 a2 01 64 5f 3a 6d 31 02 66 45 6e 74 69 74 79   ...d_:m1.fEntity
0020  a2 01 64 5f 3a 6d 32 02 66 45 6e 74 69 74 79 0a   ..d_:m2.fEntity.
0030  68 53 65 71 75 65 6e 63 65 14 a4 0d 6f 64 69 64   hSequence...odid
0040  3a 69 63 6f 72 65 3a 61 64 6d 69 6e 0e 74 32 30   :icore:admin.t20
0050  32 36 2d 30 37 2d 33 31 54 30 30 3a 30 30 3a 30   26-07-31T00:00:0
0060  30 5a 0f a1 10 68 69 6e 68 65 72 65 6e 74 11 76   0Z...hinherent.v
0070  75 72 6e 3a 69 63 6f 72 65 3a 63 6f 6e 74 65 78   urn:icore:contex
0080  74 3a 6d 61 69 6e 18 18 78 2f 68 74 74 70 73 3a   t:main..x/https:
0090  2f 2f 73 70 65 63 73 2e 69 6e 69 74 69 61 6c 63   //specs.initialc
00a0  6f 72 65 2e 6e 65 74 2f 6e 73 2f 63 6f 72 65 2d   ore.net/ns/core-
00b0  6c 64 2e 6a 73 6f 6e 6c 64                        ld.jsonld

L2: zQme7AMEaWQGk1hB1s1Lqsu8qf6c8ZjbqMr9ZVtjKXp8MH4 DAG address (dag-cbor): zCHNJrDLufTLXvNj7XBGh1fvvAfpKoqiYv7xgfoAv3wiuvrrN

9.5 Group (Map) (JSON 374 B → CBOR 189 B, 50.5%)

0000  a6 01 65 5f 3a 6d 61 70 02 65 47 72 6f 75 70 09   ..e_:map.eGroup.
0010  a2 64 62 65 74 61 a2 01 63 5f 3a 62 02 66 45 6e   .dbeta..c_:b.fEn
0020  74 69 74 79 65 61 6c 70 68 61 a2 01 63 5f 3a 61   tityealpha..c_:a
0030  02 66 45 6e 74 69 74 79 0a 63 4d 61 70 14 a4 0d   .fEntity.cMap...
0040  6f 64 69 64 3a 69 63 6f 72 65 3a 61 64 6d 69 6e   odid:icore:admin
0050  0e 74 32 30 32 36 2d 30 37 2d 33 31 54 30 30 3a   .t2026-07-31T00:
0060  30 30 3a 30 30 5a 0f a1 10 68 69 6e 68 65 72 65   00:00Z...hinhere
0070  6e 74 11 76 75 72 6e 3a 69 63 6f 72 65 3a 63 6f   nt.vurn:icore:co
0080  6e 74 65 78 74 3a 6d 61 69 6e 18 18 78 2f 68 74   ntext:main..x/ht
0090  74 70 73 3a 2f 2f 73 70 65 63 73 2e 69 6e 69 74   tps://specs.init
00a0  69 61 6c 63 6f 72 65 2e 6e 65 74 2f 6e 73 2f 63   ialcore.net/ns/c
00b0  6f 72 65 2d 6c 64 2e 6a 73 6f 6e 6c 64            ore-ld.jsonld

L2: zQmbfAq3XcXi3HZBsnGdNbYWjTydTVYHJUHnVkiNhPokuFc DAG address (dag-cbor): zCHNJomMPUQSfMfzyY3BxJCeZYZdCqAeMbb58JjRjhKauZQpv

Size summary: the §9 examples encode at 50.5–54.1% of their canonical JSON size — consistent with the family's ~50–60% compaction target (integer keys + compact type system; historical DAG-CBOR-LD claimed 60–75%, the measured CORE-LD family is tighter).

10. Conformance

10.1 Implementation requirements

A conforming CBOR-CORE-LD implementation MUST:

1. Translate bidirectionally — convert any valid CBOR-CORE-LD document to JSON-CORE-LD and any valid JSON-CORE-LD document to CBOR-CORE-LD (§2, §7). 2. Accept both key forms — integer-keyed and text-keyed maps on decode (§3.4). 3. Encode deterministically — CBOR output satisfying §5.1 on every invocation. 4. Validate @context — resolve the @context identically to JSON-CORE-LD §3. 5. Preserve containers — arrays and maps translate without structural change; tags 268/269 accepted, never emitted. 6. Handle byte strings — native major-2 on encode (when the source carries bytes), base64url text on decode (§2.2, §7.4). 7. Round-trip — JSON → CBOR → JSON preserves all CORE-LD invariants and produces a structurally identical document (RT-C1). 8. Reject non-deterministic input — duplicate map keys, indefinite-length items, non-minimal integer encodings, unknown integer keys, trailing bytes (§7.4).

10.2 Conformance levels

10.3 Conformance suite

The reference suite is test_cbor_core_ld.py (22 tests, all passing), which exercises:

• 14 round-trip tests — the five JSON-CORE-LD §9 examples (embedded), the five §9 examples extracted live from the markdown, and the four profile documents (`profile_conformance.build_doc`)
• Deterministic encoding, byte-stability (RT-C2, RT-C3)
• Integer-key compression (integer-keyed output strictly smaller than text-keyed)
• Size attestation (CBOR < canonical JSON on every test document)
• L2 hash format (multihash `0x12 0x20`, multibase `z`), determinism, provenance-exclusion semantics
• DAG address assembly (codec varint ++ multihash)
• Tag unwrapping, unknown-integer-key rejection, trailing-byte rejection

11. Registry

CBOR-CORE-LD v0.1.0 — July 31, 2026. Draft. Encodes CORE-LD v0.1.0. Mechanical translation of JSON-CORE-LD v0.1.0; binary companion in the DAG--LD specification family.*