Internet-Draft M. Norton Intended status: Informational Independent Expires: 27 January 2027 27 July 2026 SDLP RFC 3: Object Format Specification draft-norton-sdlp-obj-format-01 M. Norton Individual Submission 27 July 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-00 and resolves inconsistencies identified during interoperability analysis with Identity-02 and Lifecycle-02. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at the RFC Editor website. 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. Early drafts of the SDLP object format (obj‑format‑00) 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‑01 resolves these issues by defining: * the canonical SDLP object envelope, * the normative field ordering and encoding grammar, * deterministic serialization rules, * the canonical hashing and signing preimage, * validation requirements for relying parties, * interoperability rules for SCITT, EMILIA, and external provenance systems. 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 (SCITT). 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‑00 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 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. 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. 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. Hashing Preimage: The exact byte sequence used as input to cryptographic hash functions. The hashing preimage MUST be the canonical representation of the object envelope. 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. 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 requires deterministic canonical representation for transparency receipts and auditability. EMILIA: An external provenance and authenticity framework that relies on deterministic object encoding for cross-system interoperability. 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. All SDLP implementations MUST produce and consume objects whose envelope conforms exactly to the structure and field ordering defined in this section. 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. 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. 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. The Body MUST be included in the hashing and signing preimage. 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. 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, * 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. 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 with SCITT and EMILIA. 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. 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. 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. 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 be included exactly as provided by the lifecycle transition. Body encoding MUST be deterministic and MUST NOT vary across implementations. 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. 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. 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 such as SCITT and EMILIA. 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 serialization defined in Section 4. The hashing preimage MUST include: * DigitalID, * InstanceID, * Lineage, * Timestamp, * Body, * canonical newline separators. The hashing preimage MUST NOT include: * non-canonical whitespace, * implementation-specific metadata, * alternative encodings, * signature envelopes, * compression artifacts. Hashing MUST be performed over the exact canonical byte sequence with no normalization, trimming, or transformation. 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 SCITT and EMILIA. 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. Signatures MUST be computed over the canonical byte sequence exactly. 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 or replace the canonical representation. 5.5. Verification Rules A relying party MUST verify signatures using the following procedure: 1. Normalize the object to its canonical representation. 2. Compute the hash over the canonical envelope. 3. Verify the signature using the SigningPreimage. 4. Validate DigitalID, InstanceID, Lineage, and Timestamp. 5. 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 stored digest, * DigitalID is modified, * InstanceID or Lineage violate canonical grammar, * Timestamp is malformed. 5.6. SCITT and EMILIA Interoperability SCITT and EMILIA require deterministic hashing and signing behavior. SDLP achieves interoperability 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 transparency receipts MUST be computed over the canonical envelope. EMILIA provenance attestations MUST reference the canonical hash. 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. 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 canonical representation defined in Section 4. Any deviation from canonical encoding, field ordering, or serialization grammar constitutes a validation failure. 6.1. Validation Preconditions A relying party MUST normalize the object to its canonical representation before performing any validation. Validation MUST NOT be performed over non-canonical or partially canonical 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, * Body is encoded canonically. 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, * newline separators follow canonical rules, * 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 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 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 canonical envelope, * the signature is computed over the canonical envelope, * the signature envelope does not modify canonical fields, * the signature matches the SigningPreimage, * the hash matches 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, * 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 with SCITT and EMILIA. Any deviation from canonical encoding—such as alternative whitespace, field reordering, 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. 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, * 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 Protection SDLP prevents replay attacks through: * unique InstanceID assignment per transition, * unique Lineage extension per transition, * unique Timestamp per transition, * deterministic hashing and signing over the canonical envelope. Because each lifecycle transition produces a unique canonical representation, replaying a prior object cannot masquerade as a new transition. Relying parties MUST verify that InstanceID, Lineage, and Timestamp values are consistent with the expected lifecycle sequence. 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. BitDrop events MUST NOT be treated as valid security threats or attack scenarios; they are invalid lifecycle transitions. SDLP implementations MUST detect BitDrop conditions during canonical validation and reject the object immediately. 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. Relying parties MUST reject any object containing extraneous fields, metadata, or non-canonical formatting. 7.7. Interoperability Security SCITT and EMILIA require deterministic canonical representation for transparency receipts and provenance attestations. Security depends on: * stable canonical encoding, * stable hashing preimage, * stable signing preimage, * strict field ordering. Any deviation from canonical representation undermines cross-system validation and MUST be treated as a security failure. 7.8. Implementation Guidance Implementers SHOULD: * normalize objects before hashing or signing, * validate canonical representation before processing, * reject non-canonical encodings early, * use audited cryptographic libraries, * ensure UTF-8 correctness and stability. 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. 7.9. Summary The SDLP object format is a security-critical component of the SDLP architecture. Deterministic canonical representation, strict field ordering, 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-01] Norton, M., "SDLP RFC 3: Object Format Specification", draft-norton-sdlp-obj-format-01, 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 Working Group, "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 Working Group, "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