Internet-Draft M. Norton Intended status: Informational Independent Expires: 27 January 2027 27 July 2026 SDLP RFC 3: Lineage Specification draft-norton-sdlp-lineage-01 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com 27 July 2026 Abstract This document defines the SDLP lineage model, which provides the canonical method for representing the ancestry of SDLP-governed objects. Lineage is a structural property that records how an object evolves through duplication and transformation events. The lineage model ensures that descendant objects remain uniquely identifiable and traceable across all lifecycle transitions. This revision (lineage-01) updates and replaces draft-norton-sdlp- lineage-00. It aligns the lineage grammar with Identity-02, Lifecycle-02, and Object-Format-01, clarifies deterministic ancestry extension rules, incorporates BitDrop conditions for invalid lineage transitions, and defines normative validation requirements for relying parties. This specification provides the authoritative lineage model required for interoperable identity, lifecycle, and provenance processing across SDLP implementations. Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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. 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 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Canonical Lineage Grammar . . . . . . . . . . . . . . . . . 9 4. Deterministic Extension Rules . . . . . . . . . . . . . . . 14 5. Validation Rules . . . . . . . . . . . . . . . . . . . . . 21 6. BitDrop Conditions . . . . . . . . . . . . . . . . . . . . 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 lineage model. Lineage is the structural record of ancestry for SDLP-governed objects. It captures how an object evolves through duplication and transformation events, ensuring that descendant objects remain uniquely identifiable and traceable across all lifecycle transitions. Lineage provides the deterministic ancestry chain required for provenance, auditability, and interoperability across SDLP implementations. Early drafts of the lineage model (lineage-00) introduced the basic hierarchical grammar for representing ancestry but lacked complete rules for deterministic extension, validation, and interoperability with Identity-02, Lifecycle-02, and Object-Format-01. Implementers identified inconsistencies in ancestry extension behavior, malformed lineage segments, and ambiguity in how lineage interacts with lifecycle transitions. Lineage-01 resolves these issues by defining: * the canonical lineage grammar, * deterministic ancestry extension rules, * validation requirements for relying parties, * BitDrop conditions for invalid lineage transitions, * interoperability rules with Identity-02, Lifecycle-02, and Object-Format-01. The lineage model defined in this document is REQUIRED for: * deterministic ancestry representation, * lifecycle transition validation (Lifecycle-02), * identity preservation (Identity-02), * canonical object encoding (Object-Format-01), * provenance and auditability across SDLP implementations. All SDLP implementations MUST treat the lineage model defined in this document as normative. Any deviation from the canonical lineage grammar or deterministic extension rules constitutes a violation of SDLP semantics and MUST be rejected by relying parties. This document updates and replaces draft-norton-sdlp-lineage-00 and provides the authoritative definition of the SDLP lineage model required for interoperable identity, lifecycle, and provenance 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 lineage model. Lineage: The hierarchical ancestry record of an SDLP-governed object. Lineage reflects how an object evolves through duplication and transformation events. Lineage MUST follow the canonical grammar defined in this document. Ancestry Chain: The ordered sequence of lineage segments representing the complete history of an object. The ancestry chain grows deterministically with each lifecycle transition. Lineage Segment: A single numeric component within the lineage hierarchy. Each segment represents a child index assigned during a lifecycle transition. Lineage segments MUST be positive integers. Lineage Grammar: The normative hierarchical grammar used to encode lineage: Lineage := number *( "." number ) Lineage grammar is deterministic and MUST NOT vary across implementations. Parent Lineage: The lineage value of the object from which a descendant is derived. Parent lineage MUST be preserved exactly and extended deterministically. Child Lineage: The lineage value assigned to a descendant object. Child lineage MUST be formed by appending "." ChildIndex to the parent lineage. ChildIndex: A positive integer representing the position of a descendant relative to its siblings. ChildIndex MUST be unique among siblings and MUST follow the deterministic extension rules defined in Section 4. Deterministic Extension: The process of forming a new lineage value by extending the parent lineage with a unique ChildIndex. Deterministic extension ensures that ancestry remains stable, predictable, and verifiable. Lineage Preservation: The requirement that lineage MUST NOT be truncated, rewritten, reordered, or replaced during lifecycle transitions. Lineage preservation is normative and REQUIRED for SDLP interoperability. BitDrop: Any event that attempts to rewrite, truncate, substitute, or downgrade lineage. BitDrop events violate SDLP lifecycle semantics and MUST be rejected by relying parties. BitDrop conditions are defined in Section 6. Malformed Lineage: Any lineage value that violates the canonical grammar, contains invalid segments, or fails deterministic extension rules. Malformed lineage MUST cause validation failure. Relying Party: Any system that consumes SDLP objects and performs validation, verification, or admission decisions based on identity, lineage, lifecycle metadata, or canonical representation. Canonical Representation: The normative byte-level encoding of an SDLP object as defined in draft-norton-sdlp-obj-format-01. Lineage MUST be encoded canonically and included in the hashing and signing preimage. Ancestry Validation: The process of verifying that lineage conforms to canonical grammar, deterministic extension rules, and SDLP lifecycle semantics. Ancestry validation is REQUIRED for all relying parties. Provenance: The broader record of origin, ancestry, and lifecycle transitions associated with an SDLP-governed object. Lineage provides the structural foundation for provenance across SDLP implementations. 3. Canonical Lineage Grammar The SDLP lineage model defines the normative hierarchical grammar used to represent the ancestry of SDLP-governed objects. Lineage is a deterministic, strictly ordered sequence of positive integers that reflects how an object evolves through duplication and transformation events. All SDLP implementations MUST encode lineage using the canonical grammar defined in this section. 3.1. Lineage Structure Lineage is represented as a dot-separated hierarchy of numeric segments: Lineage := number *( "." number ) where each segment is a positive integer representing a ChildIndex assigned during a lifecycle transition. Lineage MUST contain at least one segment, and each segment MUST conform to the canonical grammar. Examples of valid lineage values include: "1" "1.2" "3.4.1" "10.7.2.5" Examples of invalid lineage values include: "0" ; zero is not permitted "1." ; trailing dot ".2" ; leading dot "1..3" ; empty segment "1.a" ; non-numeric segment "1.-3" ; negative segment 3.2. Parent and Child Lineage Parent lineage is the lineage value of the object from which a descendant is derived. Child lineage is formed by extending the parent lineage with a unique ChildIndex: ChildLineage := ParentLineage "." ChildIndex ChildIndex MUST be a positive integer and MUST be unique among siblings. ChildIndex assignment MUST follow the deterministic extension rules defined in Section 4. For example: Parent: 1.4 ChildIndex: 3 Child: 1.4.3 3.3. Deterministic Hierarchical Grammar The lineage grammar is deterministic. This means: * identical ancestry MUST produce identical lineage values, * lineage MUST NOT vary across implementations, * lineage MUST NOT include optional fields or alternative formats, * lineage MUST NOT include whitespace, padding, or metadata, * lineage MUST be encoded as a single UTF-8 string. Any deviation from the canonical grammar constitutes a malformed lineage and MUST cause validation failure. 3.4. Canonical Encoding Requirements Lineage MUST be encoded using the canonical representation defined in draft-norton-sdlp-obj-format-01. Specifically: * lineage MUST be encoded as a UTF-8 string, * lineage MUST NOT contain leading or trailing whitespace, * lineage MUST NOT contain indentation or formatting artifacts, * lineage MUST NOT contain implementation-specific metadata, * lineage MUST be included exactly as produced by the lifecycle transition. Lineage MUST be included in the hashing and signing preimage. 3.5. Lineage Preservation Lineage is immutable except for deterministic extension. SDLP implementations MUST preserve lineage exactly across all lifecycle transitions. The following modifications are prohibited: * truncation of lineage segments, * rewriting or reordering segments, * replacing lineage with a new value, * substituting non-canonical encodings, * removing or collapsing ancestry segments. Any modification to lineage other than deterministic extension constitutes a BitDrop event (Section 6) and MUST be rejected. 3.6. Malformed Lineage A lineage value is malformed if: * any segment is non-numeric, * any segment is zero or negative, * any segment contains leading zeros, * the lineage contains empty segments, * the lineage contains illegal characters, * the lineage violates canonical grammar, * the lineage violates deterministic extension rules. Malformed lineage MUST cause validation failure. 3.7. Interoperability Requirements Lineage MUST be interoperable across all SDLP implementations. To ensure interoperability: * lineage MUST follow canonical grammar, * lineage MUST be encoded deterministically, * lineage MUST be preserved exactly across transitions, * lineage MUST be validated by relying parties, * lineage MUST be included in canonical object encoding. Interoperability with Identity-02, Lifecycle-02, and Object-Format-01 requires strict adherence to the canonical lineage grammar defined in this section. 4. Deterministic Extension Rules Deterministic extension ensures that lineage grows in a predictable, verifiable, and interoperable manner across all SDLP implementations. Each lifecycle transition MUST extend lineage using a unique ChildIndex appended to the parent lineage. Deterministic extension is REQUIRED for ancestry preservation, provenance integrity, and lifecycle validation. 4.1. Extension Model Lineage extension follows a strict hierarchical model: ChildLineage := ParentLineage "." ChildIndex where: * ParentLineage is the lineage of the object being duplicated or transformed, * ChildIndex is a positive integer assigned during the transition, * ChildLineage is the resulting lineage of the descendant object. ChildIndex MUST be unique among siblings and MUST follow the rules defined in this section. 4.2. ChildIndex Requirements ChildIndex MUST satisfy the following requirements: * ChildIndex MUST be a positive integer, * ChildIndex MUST NOT be zero, * ChildIndex MUST NOT be negative, * ChildIndex MUST NOT contain leading zeros, * ChildIndex MUST be unique among siblings, * ChildIndex MUST be assigned deterministically. Examples of valid ChildIndex values: "1", "2", "3", "10" Examples of invalid ChildIndex values: "0", "-1", "01", "1.2", "a" 4.3. Deterministic Sibling Assignment Sibling objects are descendants that share the same ParentLineage. Sibling lineage values MUST be assigned deterministically: * siblings MUST have distinct ChildIndex values, * ChildIndex values MUST NOT be reused, * ChildIndex values MUST increase monotonically for a given parent. For example, if ParentLineage is "4.2", valid children include: "4.2.1", "4.2.2", "4.2.3" The following are invalid: "4.2.1", "4.2.1" ; duplicate ChildIndex "4.2.3", "4.2.2" ; non-monotonic assignment 4.4. Extension During Lifecycle Transitions Lifecycle-02 defines the canonical state machine governing SDLP transitions. Lineage MUST be extended during any transition that produces a new object instance, including: * duplication events, * transformation events, * derivation events, * any transition that yields a distinct descendant object. Lineage MUST NOT be extended during transitions that do not produce a new object instance (e.g., metadata updates that do not alter object identity or content). 4.5. Prohibited Extension Behaviors The following behaviors violate deterministic extension rules and MUST be rejected: * truncating parent lineage before extension, * rewriting or reordering parent lineage segments, * replacing parent lineage with a new value, * appending non-numeric segments, * appending multiple segments in a single transition, * skipping required ChildIndex values, * reusing ChildIndex values among siblings. Any prohibited behavior constitutes a BitDrop event (Section 6). 4.6. Extension Examples Valid extension: Parent: 1 ChildIndex: 2 Child: 1.2 Parent: 3.4 ChildIndex: 1 Child: 3.4.1 Parent: 10.7.2 ChildIndex: 5 Child: 10.7.2.5 Invalid extension: Parent: 1 Child: 2 ; lineage replaced, not extended Parent: 3.4 Child: 3.4.0 ; zero segment Parent: 3.4 Child: 3..4 ; empty segment Parent: 3.4 Child: 3.4.01 ; leading zero Parent: 3.4 Child: 3.4.a ; non-numeric segment 4.7. Deterministic Extension and Canonical Encoding Lineage extension MUST be performed before canonical encoding. The resulting lineage value MUST be encoded using the canonical representation defined in draft-norton-sdlp-obj-format-01. Relying parties MUST validate that: * the lineage value was extended deterministically, * the lineage value conforms to canonical grammar, * the lineage value is encoded as a single UTF-8 string, * no extraneous whitespace or metadata is present. 4.8. Extension and Provenance Integrity Deterministic extension ensures that ancestry remains stable and verifiable across SDLP implementations. Provenance systems (including SCITT and EMILIA) rely on deterministic lineage values to: * track object evolution, * validate ancestry chains, * detect tampering or BitDrop events, * ensure cross-system interoperability. Any deviation from deterministic extension rules undermines provenance integrity and MUST be treated as a validation failure. 5. Validation Rules Validation ensures that lineage conforms to the canonical grammar, deterministic extension rules, and lifecycle semantics 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 draft-norton-sdlp-obj-format-01. Any deviation from canonical encoding, lineage grammar, or deterministic extension rules constitutes a validation failure. 5.1. Validation Preconditions A relying party MUST normalize the object to its canonical representation before performing any lineage validation. Validation MUST NOT be performed over non-canonical or partially canonical encodings. Validation MUST ensure: * lineage is present, * lineage is encoded canonically, * lineage conforms to hierarchical grammar, * lineage extends parent lineage deterministically, * ChildIndex is valid and unique among siblings, * no prohibited modifications or BitDrop conditions are present. 5.2. Grammar Validation Grammar validation ensures that lineage conforms to the canonical hierarchical grammar defined in Section 3. Grammar validation MUST verify: * lineage := number *( "." number ), * each segment is a positive integer, * no segment contains leading zeros, * no segment is zero or negative, * no segment is empty, * no illegal characters are present, * no whitespace or formatting artifacts are present. Grammar violations MUST cause the object to be rejected. 5.3. Deterministic Extension Validation Deterministic extension validation ensures that lineage grows correctly during lifecycle transitions. Relying parties MUST verify: * ChildLineage == ParentLineage "." ChildIndex, * ChildIndex is a positive integer, * ChildIndex is unique among siblings, * ChildIndex increases monotonically for a given parent, * no lineage segments were truncated, rewritten, or reordered, * no additional segments were appended beyond the required ChildIndex. Any deviation from deterministic extension rules constitutes a BitDrop event (Section 6) and MUST cause validation failure. 5.4. Parent-Child Consistency Validation Relying parties MUST verify that lineage is consistent across parent and child objects: * Child.Lineage MUST extend Parent.Lineage, * Parent.Lineage MUST be preserved exactly, * Child.Lineage MUST NOT replace Parent.Lineage, * Child.Lineage MUST NOT collapse or omit ancestry segments, * Child.Lineage MUST NOT introduce non-numeric or malformed segments. Parent-child lineage inconsistencies MUST cause the object to be rejected. 5.5. Sibling Consistency Validation Sibling objects share the same ParentLineage. Relying parties MUST verify: * siblings have distinct ChildIndex values, * ChildIndex values are not reused, * ChildIndex values increase monotonically, * no sibling lineage violates canonical grammar. Sibling inconsistencies indicate malformed lineage and MUST cause validation failure. 5.6. Canonical Encoding Validation Lineage MUST be encoded using the canonical representation defined in draft-norton-sdlp-obj-format-01. Relying parties MUST verify: * lineage is encoded as a single UTF-8 string, * no leading or trailing whitespace is present, * no indentation or formatting artifacts are present, * no implementation-specific metadata is present, * lineage appears in the correct position within the canonical envelope. Encoding violations MUST cause the object to be rejected. 5.7. BitDrop Detection Relying parties MUST detect BitDrop conditions during lineage validation. BitDrop occurs when lineage is: * truncated, * rewritten, * reordered, * replaced, * substituted with a non-canonical value, * collapsed to hide ancestry, * extended using invalid or non-numeric segments. BitDrop conditions violate SDLP lifecycle semantics and MUST cause immediate rejection of the object. 5.8. Provenance Validation Provenance systems rely on deterministic lineage to validate ancestry chains. Relying parties MUST verify: * lineage forms a complete ancestry chain, * no gaps or discontinuities exist in lineage segments, * lineage is consistent with lifecycle transition history, * lineage is consistent with identity preservation rules, * lineage is consistent across all objects in the provenance graph. Provenance inconsistencies MUST cause validation failure. 5.9. Validation Summary Lineage validation ensures that ancestry is preserved, extended deterministically, and encoded canonically across all SDLP implementations. Relying parties MUST enforce lineage validation to maintain SDLP’s identity, lifecycle, and provenance guarantees. 6. BitDrop Conditions BitDrop refers to any event that attempts to rewrite, truncate, substitute, or downgrade lineage. BitDrop violates SDLP lifecycle semantics and MUST be rejected by relying parties before hashing, signing, or validation occur. BitDrop detection is REQUIRED for preserving ancestry integrity, preventing lineage forgery, and ensuring interoperable provenance across SDLP implementations. 6.1. Definition of BitDrop A BitDrop occurs when lineage is modified in any way other than deterministic extension. BitDrop includes: * truncating lineage segments, * rewriting lineage segments, * reordering lineage segments, * replacing lineage with a new value, * collapsing lineage to hide ancestry, * substituting non-canonical encodings, * introducing malformed or non-numeric segments, * extending lineage using invalid ChildIndex values. BitDrop MUST NOT be treated as a valid lifecycle transition. It is an invalid state and MUST cause immediate rejection of the object. 6.2. Truncation BitDrop Truncation occurs when any portion of the ancestry chain is removed. Truncation includes: * removing the final segment, * removing intermediate segments, * collapsing multiple segments into one, * shortening lineage to obscure ancestry depth. Examples: Parent: 3.4.1 Invalid Child: 3.4 ; truncated Parent: 10.7.2.5 Invalid Child: 10.7.2 ; truncated Truncation MUST cause validation failure. 6.3. Rewrite BitDrop Rewrite occurs when lineage segments are altered or replaced. Rewrite includes: * changing any numeric segment, * substituting a different ancestry chain, * replacing lineage with a new value unrelated to the parent. Examples: Parent: 1.2 Invalid Child: 1.3 ; rewritten segment Parent: 4.7.2 Invalid Child: 9.1 ; replaced lineage Rewrite MUST cause validation failure. 6.4. Reordering BitDrop Reordering occurs when lineage segments appear in a different order than the canonical ancestry chain. Reordering includes: * swapping segments, * reversing segments, * reordering segments to alter ancestry meaning. Examples: Parent: 3.4.1 Invalid Child: 4.3.1 ; segments swapped Parent: 2.5.7 Invalid Child: 7.5.2 ; reversed Reordering MUST cause validation failure. 6.5. Substitution BitDrop Substitution occurs when lineage is replaced with a non-canonical or malformed value. Substitution includes: * non-numeric segments, * negative segments, * segments with leading zeros, * illegal characters, * whitespace or formatting artifacts. Examples: "1.a" ; non-numeric "3.-1" ; negative segment "4.02" ; leading zero "5..3" ; empty segment " 1.2 " ; whitespace Substitution MUST cause validation failure. 6.6. Invalid Extension BitDrop Invalid extension occurs when lineage is extended incorrectly. Invalid extension includes: * appending multiple segments in a single transition, * skipping required ChildIndex values, * reusing ChildIndex values among siblings, * appending non-numeric ChildIndex values, * appending zero or negative ChildIndex values. Examples: Parent: 1.4 Invalid Child: 1.4.0 ; zero ChildIndex Parent: 1.4 Invalid Child: 1.4.01 ; leading zero Parent: 1.4 Invalid Child: 1.4.a ; non-numeric Parent: 1.4 Invalid Child: 1.4.2.3 ; multiple segments appended Invalid extension MUST cause validation failure. 6.7. BitDrop Detection Requirements Relying parties MUST detect BitDrop conditions during lineage validation. Detection MUST verify: * lineage extends parent lineage deterministically, * no segments were removed, rewritten, or reordered, * no malformed segments are present, * ChildIndex is valid and unique, * lineage conforms to canonical grammar, * lineage is encoded canonically. BitDrop detection MUST occur before: * hashing, * signing, * lifecycle validation, * provenance verification. 6.8. BitDrop and Provenance Integrity BitDrop undermines provenance integrity by obscuring or falsifying ancestry. Provenance systems (including SCITT and EMILIA) rely on deterministic lineage to: * validate ancestry chains, * detect tampering, * ensure cross-system interoperability, * maintain auditability. Any BitDrop condition MUST cause immediate rejection of the object. 6.9. Summary BitDrop represents any attempt to alter lineage outside deterministic extension. BitDrop violates SDLP semantics and MUST be rejected by relying parties. Strict BitDrop detection is REQUIRED for preserving identity, lineage, lifecycle, and provenance guarantees across SDLP implementations. 7. Security Considerations The SDLP lineage model provides the structural foundation for tamper-evident ancestry, provenance, and lifecycle accountability across all SDLP implementations. Security in SDLP depends critically on the deterministic lineage grammar and extension rules defined in this document. Incorrect, inconsistent, or non-canonical lineage directly weakens SDLP’s integrity model and MUST be rejected by relying parties. 7.1. Canonical Lineage Integrity Deterministic lineage is REQUIRED for hashing, signing, lifecycle validation, and interoperability with SCITT, EMILIA, and other provenance systems. Any deviation from canonical lineage grammar— including malformed segments, whitespace artifacts, or alternative encodings—constitutes a security violation. Relying parties MUST reject objects whose lineage fails canonical validation. 7.2. Deterministic Extension Integrity Security depends on the invariant that lineage MUST extend deterministically during lifecycle transitions. If an attacker attempts to alter ParentLineage, reuse ChildIndex values, or append invalid segments, the resulting lineage will violate deterministic extension rules. Relying parties MUST treat any extension mismatch as a tampering event. 7.3. Identity and Lifecycle Consistency Lineage interacts directly with Identity-02 and Lifecycle-02. The following invariants MUST hold: * DigitalID MUST be preserved exactly, * InstanceID MUST extend deterministically, * Lineage MUST extend deterministically, * Timestamp MUST be unique per transition. Incorrect lineage encoding can cause misattribution, ancestry confusion, or lifecycle ambiguity. Relying parties MUST reject objects whose lineage violates canonical grammar or deterministic extension rules. 7.4. Replay Protection SDLP prevents replay attacks through: * unique ChildIndex assignment per transition, * deterministic lineage extension, * canonical encoding of lineage, * stable hashing and signing rules. Because each lifecycle transition produces a unique canonical lineage value, replaying a prior object cannot masquerade as a new transition. Relying parties MUST verify that lineage values are consistent with the expected lifecycle sequence. 7.5. BitDrop Conditions BitDrop represents any attempt to rewrite, truncate, substitute, or downgrade lineage. BitDrop events violate SDLP lifecycle semantics and MUST be rejected before hashing, signing, or validation occur. The following conditions constitute a lineage BitDrop: * truncating lineage to hide ancestry, * rewriting lineage segments, * reordering lineage segments, * replacing lineage with a new value, * collapsing ancestry segments, * appending invalid ChildIndex values, * substituting non-canonical encodings, * injecting metadata into the lineage field. BitDrop events MUST NOT be treated as valid 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 lineage, * alter whitespace or formatting, * introduce non-canonical serialization artifacts, * add segments that influence downstream processing. Relying parties MUST reject any object containing extraneous fields, metadata, or non-canonical lineage formatting. 7.7. Interoperability Security SCITT and EMILIA require deterministic lineage for transparency receipts and provenance attestations. Security depends on: * stable canonical lineage encoding, * stable hashing preimage, * stable signing preimage, * strict hierarchical grammar. Any deviation from canonical lineage 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 lineage before processing, * reject non-canonical lineage early, * use audited cryptographic libraries, * ensure UTF-8 correctness and stability. Implementers MUST NOT: * modify lineage during transitions, * rewrite or truncate ancestry, * alter ChildIndex semantics, * introduce optional or vendor-specific lineage fields, * use non-canonical serialization formats. 7.9. Summary The SDLP lineage model is a security-critical component of the SDLP architecture. Deterministic lineage grammar, strict extension rules, and stable canonical encoding ensure that SDLP objects remain tamper-evident, verifiable, and interoperable across all implementations. Relying parties MUST enforce lineage validation to maintain SDLP’s security guarantees. 8. IANA Considerations This document has no actions for IANA. SDLP lineage values are purely structural identifiers defined by the canonical grammar and deterministic extension rules in this specification. Lineage does not require registration, allocation, or coordination of namespaces managed by IANA. No new registries are created by this document, and no existing registries require modification. 9. Normative References [Identity-02] Norton, M., "SDLP RFC 1: Identity Specification", draft-norton-sdlp-identity-02, July 2026. [Lifecycle-02] Norton, M., "SDLP RFC 2: Lifecycle Specification", draft-norton-sdlp-lifecycle-02, July 2026. [Obj-Format-01] Norton, M., "SDLP RFC 3: Object Format Specification", draft-norton-sdlp-obj-format-01, July 2026. [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. 10. Informative References [SCITT] IETF Secure Credential Infrastructure for Transparent Trust (SCITT), https://datatracker.ietf.org/wg/scitt/. [EMILIA] EMILIA Provenance and Authenticity Framework, https://emilia-project.org/. [SDLP-Arch-00] Norton, M., "SDLP RFC 0: Architecture Overview", draft-norton-sdlp-arch-00, July 2026. [SDLP-SecArch-00] Norton, M., "SDLP RFC 4: Security Architecture", draft-norton-sdlp-sec-arch-00, July 2026. [Provenance] Moreau, L., et al., "The Open Provenance Model Core Specification", December 2011. [SupplyChain] NIST, "Security and Privacy Controls for Information Systems and Organizations", NIST SP 800-53, Revision 5, September 2020. [TamperEvident] Haber, S. and Stornetta, W., "How to Time-Stamp a Digital Document", Journal of Cryptology, 1991. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com