SDLP Lineage Specification
draft-norton-sdlp-lineage-03

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: 02 February 2027                                 02 August 2026

                 SDLP Lineage Specification
                 draft-norton-sdlp-lineage-03

M. Norton
Independent
El Mirage, Arizona, USA
Email: mark433norton@gmail.com
02 August 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.

   Lineage-03 aligns the lineage grammar with Identity-02, Lifecycle-02,
   and Object-Format-07, and defines deterministic ancestry extension
   rules that produce stable, verifiable lineage across all SDLP
   implementations. This revision incorporates BitDrop conditions for
   invalid lineage transitions and specifies normative validation
   requirements for relying parties. Together with Identity-02,
   Lifecycle-02, and Object-Format-07, this document provides the
   authoritative lineage model required for interoperable identity,
   lifecycle, and provenance processing.

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 defines the SDLP 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.
   The lineage model provides the deterministic ancestry chain required
   for provenance, auditability, and interoperability across SDLP
   implementations.

   Lineage-03 defines the canonical lineage grammar, the deterministic
   rules for ancestry extension, and the validation requirements that
   relying parties MUST enforce. This specification also incorporates
   BitDrop conditions for invalid lineage transitions and defines how
   lineage interacts with Identity-02, Lifecycle-02, and Object-Format-07.

   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-07),
      * 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.

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-07. 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-07. 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-07
   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-07. 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 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-07. Any deviation from canonical
   encoding, lineage grammar, or deterministic extension rules
   constitutes a validation failure.

5.1.  Validation Preconditions

   A relying party MUST validate lineage using the canonical
   representation of the object. 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-07. 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 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 external 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

   Deterministic lineage is REQUIRED 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:

      * 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 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 Identity Specification",
              draft-norton-sdlp-identity-02, July 2026.

   [Lifecycle-02]
              Norton, M., "SDLP Lifecycle Specification",
              draft-norton-sdlp-lifecycle-02, July 2026.

   [Obj-Format-07]
              Norton, M., "SDLP Object Format Specification",
              draft-norton-sdlp-obj-format-07, August 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/.

   [SDLP-Arch-00]
              Norton, M., "SDLP Architecture Overview",
              draft-norton-sdlp-arch-00, July 2026.

   [SDLP-SecArch-00]
              Norton, M., "SDLP 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