Internet-Draft M. Norton Intended status: Informational Independent Expires: 01 February 2027 01 August 2026 SDLP Object Format Specification draft-norton-sdlp-obj-format-03 M. Norton Individual Submission 01 August 2026 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Abstract This document defines the canonical object format for the Secured Digital Lifecycle Protocol (SDLP). The object format specifies the normative byte-level representation used for hashing, signing, validation, and interoperability across SDLP implementations. All SDLP-governed objects MUST follow the canonical encoding, field ordering, and serialization grammar defined in this specification. This document updates and replaces draft-norton-sdlp-obj-format-02 and resolves inconsistencies identified during interoperability analysis with Identity-02 and Lifecycle-02. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Canonical Object Envelope . . . . . . . . . . . . . . . . 9 4. Canonical Encoding Grammar . . . . . . . . . . . . . . . 14 5. Hashing and Signing Rules . . . . . . . . . . . . . . . . 21 6. Validation Rules . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 38 9. Normative References . . . . . . . . . . . . . . . . . . 39 10. Informative References . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines a unified identity, lineage, and lifecycle framework for digital objects. Identity‑02 establishes the immutable DigitalID assigned at object creation, and Lifecycle‑02 defines the canonical state machine and transition semantics governing how SDLP objects evolve over time. This document provides the third foundational pillar of the SDLP suite: the canonical object format. The SDLP object format defines the normative byte‑level representation used for hashing, signing, validation, and interoperability across SDLP implementations. All SDLP‑governed objects MUST follow the canonical encoding, field ordering, and serialization grammar defined in this specification. The object format ensures that identity inheritance, lineage extension, and lifecycle transitions produce deterministic and verifiable results. Earlier drafts of the SDLP object format introduced preliminary encoding concepts but lacked a complete canonical grammar, deterministic serialization rules, and interoperability guarantees required by Identity‑02 and Lifecycle‑02. Implementers identified inconsistencies in field ordering, normalization behavior, and hashing preimage construction that prevented reliable validation and cross‑system interoperability. Object‑Format‑03 resolves these issues by freezing the canonical envelope grammar. The envelope now has exactly one valid byte sequence: four U+000A separators, no trailing U+000A after Body, field values that MUST NOT contain CR or LF, and a Body encoded using unpadded base64url as defined in RFC 4648 Section 5. Hashing and signing are performed over this exact byte sequence without normalization. This frozen grammar ensures that all SDLP implementations compute identical preimages, digests, and signatures for the same logical object. The canonical object format defined in this document is REQUIRED for: * DigitalID encoding (Identity‑02), * lifecycle transition validation (Lifecycle‑02), * lineage extension and ancestry representation (Lineage‑02), * tamper‑evident hashing and signing (Security‑01), * transparency receipts and auditability. All SDLP implementations MUST treat the object format defined in this document as normative. Any deviation from the canonical encoding, field ordering, or serialization grammar constitutes a violation of SDLP semantics and MUST be rejected by relying parties. This document updates and replaces draft‑norton‑sdlp‑obj‑format‑02 and provides the authoritative definition of the SDLP object format required for interoperable identity, lineage, and lifecycle processing. 2. Terminology The following terms are used throughout this document. All terms are descriptive unless explicitly marked as normative. Identity-related terms are defined in draft-norton-sdlp-identity-02 and lifecycle terms are defined in draft-norton-sdlp-lifecycle-02. This section defines terminology specific to the SDLP object format. Canonical Representation: The normative byte-level encoding of an SDLP object. Canonical representation is deterministic, stable, and used for hashing, signing, validation, and interoperability. All SDLP objects MUST be serialized using the canonical representation defined in this document. Object-Format-03 freezes the canonical grammar so that each logical object has exactly one valid byte sequence. Object Envelope: The top-level structure of an SDLP object. The envelope contains the DigitalID, InstanceID, Lineage, Timestamp, and the object body. The envelope is serialized using the canonical encoding grammar defined in Section 4, which specifies exactly four U+000A separators and prohibits any trailing U+000A after Body. Object Header: The portion of the object envelope containing DigitalID, InstanceID, Lineage, and Timestamp. The header is always encoded before the object body and follows strict field ordering rules. Object Body: The content, payload, or data associated with an SDLP object. The body may represent media, metadata, structured data, or any other digital content. The body is included in canonical representation and MUST follow the encoding rules defined in this specification, including unpadded base64url encoding as defined in RFC 4648 Section 5. Field Ordering: The normative sequence in which fields MUST appear in the canonical representation. Field ordering is fixed and MUST NOT vary across implementations. Any deviation constitutes a canonicalization error. Serialization Grammar: The normative encoding rules governing how fields, values, arrays, and nested structures are serialized. The serialization grammar ensures deterministic byte-level output across all SDLP implementations. The grammar defined in Object-Format-03 is frozen and MUST NOT be altered by implementations. Hashing Preimage: The exact byte sequence used as input to cryptographic hash functions. The hashing preimage MUST be the canonical envelope defined in Section 4. Any other input is invalid. Signing Preimage: The exact byte sequence used as input to digital signature algorithms. The signing preimage MUST be identical to the hashing preimage unless otherwise specified by Security-01. Normalization: The process of converting an SDLP object into its canonical representation. Normalization MUST be deterministic and MUST NOT alter semantic content. Normalization rules are defined in Section 4. Verifiers MUST validate signatures over the received bytes and MUST NOT normalize input prior to verification. Deterministic Encoding: An encoding process that produces identical byte sequences for identical logical objects across all compliant implementations. Deterministic encoding is REQUIRED for hashing, signing, and interoperability. Relying Party: Any system that consumes SDLP objects and performs validation, verification, or admission decisions based on canonical representation, identity, lineage, or lifecycle metadata. SCITT: The IETF Secure Credential Infrastructure for Transparent Trust. SCITT profiles MAY carry the digest of the canonical envelope for transparency receipts and auditability. SCITT does not require the SDLP envelope itself. EMILIA: An external provenance and authenticity framework. EMILIA profiles MAY incorporate the digest of the canonical envelope for cross-system interoperability. EMILIA does not require the SDLP encoding. Canonical Error: Any deviation from the canonical representation, field ordering, or serialization grammar. Canonical errors MUST cause relying parties to reject the object. 3. Canonical Object Envelope The canonical object envelope defines the top-level structure of all SDLP-governed objects. The envelope contains the identity fields, lifecycle fields, and object body, all serialized using the canonical encoding grammar defined in Section 4. The envelope is the normative unit of hashing, signing, validation, and interoperability. Object-Format-03 freezes the canonical envelope grammar. The envelope has exactly one valid byte sequence: four U+000A separators, no trailing U+000A after Body, field values that MUST NOT contain CR or LF, and a Body encoded using unpadded base64url as defined in RFC 4648 Section 5. Hashing and signing are performed over this exact byte sequence without normalization. Any deviation constitutes a canonicalization error and MUST cause relying parties to reject the object. 3.1. Envelope Structure An SDLP object envelope consists of the following components: * DigitalID * InstanceID * Lineage * Timestamp * Body These components MUST appear in the canonical representation in the exact order listed above. Field ordering is normative and MUST NOT be altered by any implementation. The canonical envelope is represented conceptually as: Envelope := { DigitalID, InstanceID, Lineage, Timestamp, Body } The envelope is serialized using the deterministic encoding grammar defined in Section 4. The envelope MUST NOT include optional fields, alternative encodings, or implementation-specific metadata. The grammar defined in this document is frozen and MUST NOT be altered by implementations. 3.2. DigitalID Component DigitalID is the immutable identity tuple defined in Identity-02. DigitalID uniquely identifies the origin object and is inherited unchanged by all descendants. DigitalID MUST appear first in the canonical envelope. DigitalID MUST be encoded using the canonical grammar defined in Identity-02 and MUST NOT be modified, reordered, or re-encoded during lifecycle transitions. 3.3. InstanceID Component InstanceID is the per-object identifier assigned at each lifecycle transition. InstanceID MUST follow the hierarchical grammar defined in draft-norton-sdlp-lifecycle-02. InstanceID MUST appear immediately after DigitalID in the canonical envelope. InstanceID MUST be encoded as a canonical string using the serialization grammar defined in Section 4. 3.4. Lineage Component Lineage reflects the complete ancestry of the object. Lineage MUST follow the hierarchical grammar defined in draft-norton-sdlp-lifecycle-02 and MUST grow deterministically with each lifecycle transition. Lineage MUST appear immediately after InstanceID in the canonical envelope. Lineage MUST be encoded as a canonical string using the serialization grammar defined in Section 4. 3.5. Timestamp Component Timestamp reflects the moment the lifecycle transition occurred. Timestamp MUST follow the canonical grammar defined in Lifecycle-02: Date := YYYY-MM-DD Time := HH:MM:SS Timestamp := Date "T" Time Timestamp MUST appear immediately after Lineage in the canonical envelope. Timestamp MUST be encoded as a canonical string. Timestamp values MUST NOT contain CR, LF, or timezone suffixes. 3.6. Body Component The Body contains the content, payload, or data associated with the SDLP object. The Body may represent media, metadata, structured data, or any other digital content. The Body MUST appear last in the canonical envelope. The Body MUST be encoded using the canonical serialization grammar defined in Section 4, including unpadded base64url encoding. The Body MUST NOT contain CR or LF. The Body MUST be included in the hashing and signing preimage, and no trailing U+000A MUST follow the Body. 3.7. Envelope Determinism Requirements The canonical envelope is deterministic if and only if: * all fields appear in the normative order, * all fields are encoded using the canonical grammar, * no optional fields or alternative encodings are present, * DigitalID is preserved exactly, * InstanceID, Lineage, and Timestamp follow Lifecycle-02 rules, * the Body is encoded deterministically using unpadded base64url, * exactly four U+000A separators are present, * no trailing U+000A follows the Body. Deterministic envelopes are REQUIRED for hashing, signing, interoperability, and validation. 3.8. Envelope Validation A relying party MUST validate the canonical envelope before accepting an SDLP object. Envelope validation MUST ensure: * field ordering is correct, * DigitalID is valid (Identity-02), * InstanceID and Lineage follow canonical grammar, * Timestamp is well-formed, * Body is encoded canonically using unpadded base64url, * exactly four U+000A separators are present, * no trailing U+000A follows the Body, * no extraneous fields or metadata are present. Envelope validation failures MUST cause the object to be rejected. 4. Canonical Encoding Grammar The canonical encoding grammar defines the normative byte-level serialization rules for all SDLP objects. The grammar ensures that every SDLP implementation produces identical canonical representations for identical logical objects, enabling deterministic hashing, signing, validation, and interoperability. Object-Format-03 freezes the canonical encoding grammar. The grammar defines exactly one valid byte sequence for each logical object: four U+000A separators, no trailing U+000A after Body, field values that MUST NOT contain CR or LF, and a Body encoded using unpadded base64url as defined in RFC 4648 Section 5. Hashing and signing are performed over this exact byte sequence without normalization. All SDLP-governed objects MUST be serialized using the canonical encoding grammar defined in this section. Any deviation constitutes a canonicalization error and MUST cause relying parties to reject the object. 4.1. Deterministic Serialization Requirements Canonical serialization MUST satisfy the following requirements: * deterministic: identical logical objects produce identical bytes, * stable: encoding rules MUST NOT vary across implementations, * complete: all fields in the envelope MUST be serialized, * ordered: fields MUST appear in the normative sequence defined in Section 3, * unambiguous: no optional fields, alternative encodings, or implementation-specific metadata are permitted, * strict: whitespace, formatting, and structural rules MUST be applied exactly. Deterministic serialization is REQUIRED for hashing, signing, lifecycle validation, and interoperability. SCITT and EMILIA profiles MAY incorporate the digest of the canonical envelope; neither system requires the SDLP envelope itself. 4.2. Encoding Model SDLP uses a strict, text-based canonical encoding model. All fields are serialized as UTF-8 strings using the grammar defined in this section. No binary encodings, compression schemes, or alternative serialization formats are permitted. The canonical representation is conceptually: Canonical := DigitalID "\n" InstanceID "\n" Lineage "\n" Timestamp "\n" Body where each component is encoded using the rules defined below. The grammar is frozen and MUST NOT be altered by implementations. 4.3. String Encoding Rules All SDLP fields MUST be encoded as UTF-8 strings. The following rules apply: * no leading or trailing whitespace, * no indentation or formatting characters, * no optional whitespace between tokens, * no alternative quoting or escaping conventions, * no normalization beyond UTF-8 encoding, * field values MUST NOT contain CR or LF. Strings MUST be encoded exactly as defined in Identity-02 and Lifecycle-02. 4.4. Field Ordering Rules Fields MUST appear in the canonical representation in the following order: 1. DigitalID 2. InstanceID 3. Lineage 4. Timestamp 5. Body Field ordering is normative. Any deviation constitutes a canonical error. 4.5. DigitalID Encoding DigitalID MUST be encoded using the canonical grammar defined in Identity-02. DigitalID MUST appear exactly as assigned at origin and MUST NOT be modified during lifecycle transitions. DigitalID MUST be encoded as a single UTF-8 string. 4.6. InstanceID Encoding InstanceID MUST be encoded using the hierarchical grammar defined in Lifecycle-02: InstanceID := number *( "." number ) InstanceID MUST be encoded as a single UTF-8 string with no whitespace, padding, or alternative separators. 4.7. Lineage Encoding Lineage MUST be encoded using the hierarchical grammar defined in Lifecycle-02: Lineage := number *( "." number ) Lineage MUST reflect the complete ancestry of the object and MUST be encoded as a single UTF-8 string. 4.8. Timestamp Encoding Timestamp MUST follow the canonical grammar defined in Lifecycle-02: Date := YYYY "-" MM "-" DD Time := HH ":" MM ":" SS Timestamp := Date "T" Time Timestamp MUST be encoded as a single UTF-8 string. Timestamp values MUST NOT contain CR, LF, or timezone suffixes. 4.9. Body Encoding The Body contains the object’s content or payload. The Body MUST be encoded as a UTF-8 string using the following rules: * Body MUST NOT contain leading or trailing whitespace, * Body MUST NOT contain indentation or formatting artifacts, * Body MUST NOT contain implementation-specific metadata, * Body MUST NOT contain CR or LF, * Body MUST be included exactly as provided by the lifecycle transition. Binary Bodies (e.g., media, structured data, or arbitrary byte sequences) MUST be encoded using URL-safe Base64 without padding. The Base64 value MUST represent the exact raw bytes of the Body and MUST be included verbatim in the canonical representation. 4.10. Canonical Newline Rules The canonical representation MUST use the newline character: "\n" (U+000A) Newlines MUST appear only between the envelope fields defined in Section 3. Newlines MUST NOT appear within DigitalID, InstanceID, Lineage, or Timestamp. The canonical envelope contains exactly four U+000A separators and MUST NOT contain a trailing U+000A after Body. Any other newline placement constitutes a canonicalization error. 4.11. Prohibited Encodings The following encodings MUST NOT be used: * JSON, CBOR, XML, or other structured formats, * binary encodings, * compression formats, * whitespace-normalized formats, * implementation-specific serialization schemes. Any prohibited encoding constitutes a canonical error. 4.12. Canonicalization Errors A relying party MUST reject an SDLP object if: * field ordering is incorrect, * any field violates its encoding grammar, * whitespace rules are violated, * prohibited encodings are used, * DigitalID is modified or re-encoded, * InstanceID or Lineage violate hierarchical grammar, * Timestamp is malformed, * Body is not encoded canonically, * newline placement violates Section 4.10. Canonicalization errors MUST be surfaced to the relying party or verifier. 5. Hashing and Signing Rules This section defines the normative hashing and signing rules for all SDLP objects. Hashing and signing provide tamper-evident integrity, lifecycle accountability, and interoperability with external provenance systems. Object-Format-03 freezes the hashing and signing preimage to ensure that each logical object has exactly one valid byte sequence. All SDLP implementations MUST compute hashes and signatures using the canonical representation defined in Section 4. Any deviation constitutes a canonicalization error and MUST cause relying parties to reject the object. 5.1. Hashing Preimage The hashing preimage is the exact byte sequence used as input to cryptographic hash functions. The hashing preimage MUST be: HashPreimage := CanonicalEnvelope where CanonicalEnvelope is the deterministic, five-field, LF-delimited SDLP envelope defined in Section 4. The hashing preimage MUST include: * DigitalID, * InstanceID, * Lineage, * Timestamp, * Body (unpadded base64url of raw bytes), * exactly four U+000A separators. The hashing preimage MUST represent the canonical envelope exactly as serialized. A trailing U+000A after the Body MUST NOT appear in the canonical envelope and MUST NOT be included in the hashing preimage. The hashing preimage MUST NOT include: * non-canonical whitespace, * implementation-specific metadata, * alternative encodings (including JSON, CBOR, XML), * signature envelopes, * compression artifacts, * any normalization beyond UTF-8 encoding. Hashing MUST be performed over the exact canonical byte sequence with no trimming, transformation, reinterpretation, or normalization. 5.2. Hash Function Requirements SDLP does not mandate a specific hash algorithm, but all compliant implementations MUST use a cryptographic hash function that: * is collision-resistant, * is preimage-resistant, * is widely deployed and audited, * produces a fixed-length output. SHA-256 is RECOMMENDED for interoperability with external provenance systems. Relying parties MUST reject objects hashed with non-cryptographic or deprecated algorithms. 5.3. Signing Preimage The signing preimage is the exact byte sequence used as input to digital signature algorithms. The signing preimage MUST be identical to the hashing preimage: SigningPreimage := HashPreimage unless otherwise specified by SDLP Security-01. Implementations MUST NOT sign: * non-canonical representations, * partial envelopes, * modified or normalized variants, * metadata not included in the canonical envelope, * alternative encodings of the Body. Signatures MUST be computed over the canonical byte sequence exactly. The signature MUST cover the complete LF-delimited SDLP envelope, including all four U+000A separators and the unpadded base64url Body value representing the exact raw bytes of the object. 5.4. Signature Envelope A signature envelope contains the digital signature and associated metadata. The signature envelope MUST NOT be included in the hashing or signing preimage. The signature envelope MAY contain: * signature algorithm identifier, * public key identifier, * signature value, * optional certificate chain. Signature envelopes MUST NOT modify, replace, or reinterpret the canonical representation. 5.5. Verification Rules A relying party MUST verify signatures using the following procedure: 1. Parse the received bytes exactly as provided. 2. Confirm that the received bytes satisfy the canonical grammar defined in Section 4. 3. Compute the hash over the received canonical envelope bytes. 4. Verify the signature using the SigningPreimage. 5. Validate DigitalID, InstanceID, Lineage, and Timestamp. 6. Validate lifecycle state and transition correctness (Lifecycle-02). Verification MUST fail if: * canonicalization fails, * the signature does not match the SigningPreimage, * the hash does not match the canonical envelope, * DigitalID is modified or re-encoded, * InstanceID or Lineage violate canonical grammar, * Timestamp is malformed, * Body is not encoded as unpadded base64url of raw bytes. Verifiers MUST NOT normalize input prior to signature verification. Acceptance requires byte equality between the received envelope and the hashing/signing preimage. 5.6. SCITT and EMILIA Interoperability SDLP achieves interoperability with external provenance systems by: * using a stable canonical encoding grammar, * defining a single hashing preimage, * defining a single signing preimage, * prohibiting alternative encodings, * prohibiting metadata in the canonical envelope. SCITT and EMILIA profiles MAY incorporate the digest of the canonical envelope. Neither system requires the SDLP envelope itself, and no external system mandates SDLP-specific encoding. 5.7. Hashing and Signing Errors A relying party MUST reject an SDLP object if: * the hashing preimage is non-canonical, * the signature is computed over a non-canonical representation, * the signature envelope modifies canonical fields, * the hash does not match the canonical envelope, * the signature fails verification, * prohibited encodings are used, * the Body is not encoded as unpadded base64url of raw bytes. Hashing and signing errors MUST be surfaced to the verifier or relying party. 6. Validation Rules Validation ensures that SDLP objects conform to the canonical representation, identity semantics, lineage grammar, and lifecycle rules defined across the SDLP specification suite. Relying parties, verifiers, and SDLP-aware systems MUST apply the validation procedures described in this section before accepting any SDLP object as admissible. Validation MUST be performed over the received canonical envelope bytes. Verifiers MUST NOT normalize input prior to validation. Any deviation from canonical encoding, field ordering, or serialization grammar constitutes a validation failure. 6.1. Validation Preconditions A relying party MUST parse the received bytes exactly as provided and confirm that those bytes satisfy the canonical grammar defined in Section 4. Validation MUST NOT be performed over normalized, reconstructed, partially canonical, or alternative encodings. Validation MUST ensure: * the envelope is well-formed, * all required fields are present, * field ordering is correct, * no prohibited fields or metadata are present, * DigitalID is valid (Identity-02), * InstanceID and Lineage follow hierarchical grammar (Lifecycle-02), * Timestamp is well-formed and contains no timezone suffix, * Body is encoded canonically as unpadded base64url of raw bytes, * exactly four U+000A separators are present, * no trailing U+000A follows the Body. 6.2. Envelope Validation Envelope validation ensures that the top-level structure of the SDLP object conforms to Section 3. Envelope validation MUST verify: * DigitalID appears first, * InstanceID appears second, * Lineage appears third, * Timestamp appears fourth, * Body appears last, * each field is encoded as a UTF-8 string, * field values contain no CR or LF, * newline separators follow canonical rules (U+000A), * the envelope consists of exactly five fields and four separators, * no trailing U+000A follows the Body, * no additional fields or metadata are present. Envelope validation failures MUST cause the object to be rejected. 6.3. Identity Validation Identity validation ensures that DigitalID is preserved exactly across lifecycle transitions. Identity validation MUST verify: * Child.DigitalID == Parent.DigitalID (byte-wise equality), * no DigitalID fields differ, * no DigitalID fields have been regenerated or replaced, * DigitalID conforms to Identity-02 encoding grammar. Identity validation failures MUST cause the object to be rejected. 6.4. InstanceID Validation InstanceID validation ensures that lifecycle transitions follow the canonical hierarchical grammar. InstanceID validation MUST verify: * InstanceID := number *( "." number ), * InstanceID extends the parent InstanceID by appending "." ChildIndex, * ChildIndex is a positive integer, * ChildIndex is unique among siblings, * no truncation, rewriting, or reordering has occurred. InstanceID validation failures MUST cause the object to be rejected. 6.5. Lineage Validation Lineage validation ensures that ancestry is preserved and extended deterministically. Lineage validation MUST verify: * Lineage := number *( "." number ), * Lineage extends the parent Lineage by appending "." ChildIndex, * Lineage reflects complete ancestry, * no truncation or rewriting has occurred, * no malformed segments are present. Lineage validation failures MUST cause the object to be rejected. 6.6. Timestamp Validation Timestamp validation ensures that lifecycle transitions record the correct moment of creation. Timestamp validation MUST verify: * Timestamp := YYYY-MM-DD "T" HH:MM:SS, * Timestamp is well-formed, * Timestamp contains no timezone suffix, * Timestamp is not reused across transitions, * Timestamp is distinct from the immutable Date and Time fields in DigitalID. Timestamp validation failures MUST cause the object to be rejected. 6.7. Body Validation Body validation ensures that the object’s content is encoded canonically. Body validation MUST verify: * Body is encoded as a UTF-8 string, * Body contains no leading or trailing whitespace, * Body contains no indentation or formatting artifacts, * Body contains no implementation-specific metadata, * Body contains no CR or LF, * Body is encoded as unpadded base64url (RFC 4648 §5), * the Base64 value represents the exact raw bytes of the object’s content, * Body is included exactly as provided by the lifecycle transition. Body validation failures MUST cause the object to be rejected. 6.8. Hash and Signature Validation Hash and signature validation MUST follow Section 5. Relying parties MUST verify: * the hash is computed over the received canonical envelope bytes, * the signature is computed over the received canonical envelope, * the signature envelope does not modify canonical fields, * the signature matches the SigningPreimage, * the hash matches the canonical envelope exactly, * all newline separators are canonical (U+000A), * the Body is the exact unpadded base64url value included in the canonical envelope. Hash or signature validation failures MUST cause the object to be rejected. 6.9. Canonicalization Errors A relying party MUST reject an SDLP object if any of the following canonicalization errors occur: * incorrect field ordering, * malformed DigitalID, InstanceID, Lineage, or Timestamp, * prohibited encodings (JSON, CBOR, XML, binary), * non-canonical whitespace, * missing or extraneous fields, * modified DigitalID, * malformed hierarchical grammar, * Body not encoded as unpadded base64url of raw bytes, * incorrect newline placement, * malformed canonical envelope. Canonicalization errors MUST be surfaced to the verifier or relying party. 7. Security Considerations The SDLP object format provides the foundation for tamper-evident identity, lineage, and lifecycle guarantees across all SDLP implementations. Security in SDLP depends critically on the deterministic canonical representation defined in this document. Incorrect, inconsistent, or non-canonical encodings directly weaken SDLP’s integrity model and MUST be rejected by relying parties. 7.1. Canonical Representation Integrity The canonical encoding grammar defined in Section 4 ensures that all SDLP objects produce identical byte-level representations across implementations. Deterministic canonical representation is REQUIRED for hashing, signing, lifecycle validation, and interoperability. The canonical envelope consists of exactly five UTF-8 fields separated by four LF (U+000A) characters, with the Body encoded as unpadded base64url of raw bytes. Any deviation from this representation—such as alternative whitespace, field reordering, malformed Base64, or non-canonical serialization—constitutes a security violation. Relying parties MUST reject objects that fail canonicalization. 7.2. Hashing and Signing Integrity Hashing and signing rules defined in Section 5 ensure that SDLP objects cannot be modified without detection. Security depends on the following invariants: * the hashing preimage MUST be the canonical envelope, * the signing preimage MUST be identical to the hashing preimage, * signatures MUST NOT be computed over non-canonical encodings, * signature envelopes MUST NOT modify canonical fields, * newline separators MUST be canonical (U+000A), * the Body MUST be the exact unpadded base64url value included in the envelope. If an attacker attempts to alter DigitalID, InstanceID, Lineage, Timestamp, or Body, the canonical hash will change and signature verification will fail. Relying parties MUST treat any mismatch as a tampering event. 7.3. Identity and Lineage Integrity Identity-02 and Lifecycle-02 define strict rules for DigitalID, InstanceID, and Lineage. The object format enforces these rules by requiring: * DigitalID to be preserved exactly (byte-wise equality), * InstanceID to follow hierarchical grammar, * Lineage to reflect complete ancestry, * Timestamp to be unique per transition. Incorrect identity or lineage encoding can cause misattribution, ancestry confusion, or lifecycle ambiguity. Relying parties MUST reject objects whose identity or lineage fields violate canonical grammar. 7.4. Replay Considerations SDLP does not, by itself, prevent replay attacks. A correctly signed canonical envelope can be replayed byte-for-byte. Unique InstanceID, Lineage, and Timestamp values detect modification, but they do not establish freshness or one-time use. Replay resistance requires relying-party state, such as: * an accepted-InstanceID registry, * monotonic lineage tracking, * nonce or challenge mechanisms, * transparency-log uniqueness checks, * atomic one-time consumption semantics. A stateless verifier can only report that the object is authentic and previously well-formed. 7.5. BitDrop Conditions SDLP defines a BitDrop as any event that attempts to rewrite, truncate, substitute, or downgrade identity, lineage, or canonical representation. BitDrop events violate SDLP lifecycle semantics and MUST be rejected before hashing, signing, or validation occur. The following conditions constitute a BitDrop: * replacing a child object with its parent, * truncating lineage to hide ancestry, * rewriting InstanceID to alter transition order, * modifying Timestamp to obscure event timing, * substituting non-canonical encodings, * injecting metadata into the canonical envelope, * altering DigitalID in any way, * altering the Base64 Body value or its underlying raw bytes. BitDrop events are invalid lifecycle-transition attempts and MUST be rejected, logged, and surfaced to policy. They are relevant to threat modeling because adversaries may submit them. 7.6. Metadata Injection Protection SDLP prohibits optional fields, alternative encodings, and implementation-specific metadata. Metadata injection attacks may attempt to: * embed hidden fields in the envelope, * alter whitespace or formatting, * introduce non-canonical serialization artifacts, * add fields that influence downstream processing, * modify the Base64 Body value or introduce padding. Relying parties MUST reject any object containing extraneous fields, metadata, or non-canonical formatting. 7.7. Interoperability Security SDLP achieves interoperability with external provenance systems by defining a stable canonical envelope, a single hashing preimage, and a single signing preimage. SCITT and EMILIA profiles MAY incorporate the digest of the canonical envelope. Neither system requires the SDLP envelope itself, and no external system mandates SDLP-specific encoding. Any deviation from canonical representation undermines cross-system validation and MUST be treated as a security failure. 7.8. Implementation Guidance Implementers SHOULD: * validate canonical representation before processing, * reject non-canonical encodings early, * use audited cryptographic libraries, * ensure UTF-8 correctness and stability, * ensure Base64 encoding is URL-safe and unpadded. Implementers MUST NOT: * modify DigitalID during transitions, * rewrite InstanceID or Lineage, * alter Timestamp semantics, * introduce optional or vendor-specific fields, * use non-canonical serialization formats, * alter newline separators, * alter the Base64 Body value. 7.9. Summary The SDLP object format is a security-critical component of the SDLP architecture. Deterministic canonical representation, strict field ordering, canonical newline rules, unpadded base64url Body encoding, and stable hashing and signing rules ensure that SDLP objects remain tamper-evident, verifiable, and interoperable across all implementations. Relying parties MUST enforce canonicalization and validation to maintain SDLP’s security guarantees. 8. IANA Considerations This document has no IANA actions. SDLP does not define protocol parameters, registries, code points, or other values requiring IANA allocation or management. All identifiers used in SDLP (DigitalID, InstanceID, Lineage, Timestamp) are defined deterministically by SDLP specifications and do not require external registration. Future SDLP documents MAY introduce optional registries for object types, transformation classes, or provenance metadata. Any such registries would be defined in their respective documents and are not required by the canonical object format. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [SDLP-Identity-02] Norton, M., "SDLP RFC 1: Digital Identity Structure", draft-norton-sdlp-identity-02, July 2026. [SDLP-Lifecycle-02] Norton, M., "SDLP RFC 2: Lifecycle State Machine and Transition Rules", draft-norton-sdlp-lifecycle-02, July 2026. [SDLP-Obj-Format-02] Norton, M., "SDLP RFC 3: Object Format Specification", draft-norton-sdlp-obj-format-02, July 2026. [SDLP-Lineage-00] Norton, M., "SDLP RFC 4: Lineage Structure and Ancestry Grammar", draft-norton-sdlp-lineage-00 (work in progress), July 2026. [SCITT-Architecture] IETF SCITT Working Group, "SCITT Architecture", draft-ietf-scitt-architecture, work in progress. [EMILIA] "EMILIA Provenance and Authenticity Framework", work in progress. 10. Informative References [SDLP-Architecture] Norton, M., "SDLP RFC 0: Architectural Overview", draft-norton-sdlp-architecture-00 (work in progress), July 2026. [SDLP-Physics-00] Norton, M., "SDLP RFC 5: Representation, Semantics, and Physical Mapping", draft-norton-sdlp-physics-00 (work in progress), July 2026. [SCITT-Use-Cases] IETF SCITT Working Group, "SCITT Use Cases", draft-ietf-scitt-use-cases, work in progress. [SCITT-Receipts] IETF SCITT Working Group, "SCITT Transparency Receipts", draft-ietf-scitt-receipts, work in progress. [EMILIA-Overview] "EMILIA: Provenance and Authenticity Overview", work in progress. [C2PA] Coalition for Content Provenance and Authenticity (C2PA), "C2PA Specification", Version 2.0, 2025. [W3C-VC] World Wide Web Consortium, "Verifiable Credentials Data Model", W3C Recommendation, 2022. [W3C-DID] World Wide Web Consortium, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, 2022. [NIST-Hash] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, 2015. [NIST-Digital-Signatures] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, 2023. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com