Internet-Draft M. Norton Intended status: Informational Independent Expires: February 05, 2027 August 05, 2026 SDLP Lifecycle Specification draft-norton-sdlp-lifecycle-03 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com August 2026 Abstract This document defines the SDLP Lifecycle Specification, the canonical state machine and transition semantics governing how SDLP objects evolve over time. The lifecycle model establishes deterministic rules for object creation, activation, transformation, and termination, ensuring that identity, lineage, and lifecycle metadata remain tamper-evident and verifiable across all implementations. Lifecycle-03 updates and aligns the transition grammar with Identity-02, Lineage-03, and Object-Format-08, providing a unified framework in which DigitalID is immutable, InstanceID grows deterministically, Lineage reflects complete ancestry, and Timestamp records the precise moment of each transition. The lifecycle rules defined in this document are normative and required for interoperable SDLP processing, validation, and provenance assurance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Lifecycle State Vocabulary (Normative) . . . . . . . . . . . 7 4. Transition Rules . . . . . . . . . . . . . . . . . . . . . . 10 5. Canonical Transition Grammar . . . . . . . . . . . . . . . . 14 6. Transition Classes (Normative) . . . . . . . . . . . . . . . . 17 7. Lifecycle Validation Rules . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Normative References . . . . . . . . . . . . . . . . . . . . 31 11. Informative References . . . . . . . . . . . . . . . . . . . 33 Appendix A. Canonical Lifecycle Example (Informative) . . . . . . 35 1. Introduction The SDLP Lifecycle Specification defines the normative state machine governing how SDLP objects evolve from creation to termination. The lifecycle model provides deterministic rules for object initialization, activation, transformation, retirement, and zeroization, ensuring that identity, lineage, and lifecycle metadata remain stable, verifiable, and tamper-evident across all implementations. SDLP objects are immutable once created; lifecycle transitions do not rewrite or replace objects but instead produce new child objects whose DigitalID, InstanceID, Lineage, and Timestamp reflect the precise semantics of the transition. This deterministic growth model enables reliable provenance tracking, transparent ancestry, and consistent validation across distributed systems. Lifecycle-03 aligns the transition grammar with Identity-02, Lineage-03, and Object-Format-08. DigitalID is immutable and preserved byte-for-byte across all transitions. InstanceID grows hierarchically according to canonical rules. Lineage reflects complete ancestry and extends deterministically with each transition. Timestamp records the exact moment of creation for each object and MUST NOT be reused. The lifecycle rules defined in this document are normative and required for interoperable SDLP processing. They ensure that all SDLP-aware systems—verifiers, relying parties, transparency logs, and provenance services—interpret lifecycle transitions consistently and reject any object that violates canonical grammar or lifecycle semantics. This document defines the lifecycle vocabulary, transition rules, canonical transition grammar, validation requirements, and security considerations necessary for correct SDLP lifecycle processing. 2. Terminology The following terms are used throughout this document and are normative unless otherwise stated. All SDLP terminology aligns with Identity-02, Lineage-03, and Object-Format-08. SDLP Object A canonical, immutable envelope consisting of DigitalID, InstanceID, Lineage, Timestamp, and Body, encoded according to Object-Format-08. Each lifecycle transition produces a new SDLP object. DigitalID The immutable identifier defined in Identity-02. DigitalID is preserved byte-for-byte across all lifecycle transitions and uniquely identifies the logical entity represented by the SDLP object. InstanceID The hierarchical lifecycle index defined in Lifecycle-03. Each transition appends a positive integer ChildIndex to the parent’s InstanceID, forming a deterministic growth path. Lineage The ancestry grammar defined in Lineage-03. Lineage reflects the complete transition history of an SDLP object and grows deterministically with each lifecycle event. Timestamp The moment of creation for an SDLP object, encoded as YYYY-MM-DD "T" HH:MM:SS with no timezone suffix. Timestamp MUST be unique per transition and MUST NOT be reused. Parent The SDLP object that precedes a lifecycle transition. The parent’s DigitalID, InstanceID, and Lineage determine the canonical values used to construct the child object. Child The SDLP object produced by a lifecycle transition. The child inherits DigitalID from its parent and extends InstanceID and Lineage according to canonical rules. Lifecycle Transition A deterministic operation that produces a new SDLP object from an existing one. Lifecycle transitions include Init, Activate, Transform, Retire, and Zeroize. State The conceptual lifecycle condition of an SDLP object. States are descriptive and do not appear in the canonical envelope; they are inferred from transition semantics. Transition Class A normative category describing the semantics of a lifecycle transition. Transition classes define the rules governing how DigitalID, InstanceID, Lineage, Timestamp, and Body evolve. Canonical Envelope The LF-delimited five-field representation defined in Object-Format-08. All lifecycle transitions MUST produce objects encoded in canonical envelope form. BitDrop Any attempt to rewrite, truncate, substitute, or downgrade identity, lineage, or canonical representation. BitDrop events violate lifecycle semantics and MUST be rejected. Relying Party Any system that validates, processes, or interprets SDLP objects, including verifiers, transparency logs, provenance services, and downstream consumers. Verifier A system that performs canonicalization, hashing, signature validation, and lifecycle validation on SDLP objects. Raw Bytes The exact byte sequence represented by the Body field. Raw bytes MUST be encoded as unpadded base64url and MUST NOT be modified during lifecycle transitions. Canonical Grammar The normative encoding rules defined in Object-Format-08. All SDLP objects MUST conform to canonical grammar for lifecycle validation and interoperability. 3. Lifecycle State Vocabulary (Normative) This section defines the normative vocabulary used to describe SDLP lifecycle states. States are conceptual and do not appear in the canonical envelope; they are inferred from the transition semantics defined in this document. All SDLP implementations MUST interpret lifecycle states consistently to ensure interoperable provenance, validation, and lifecycle reasoning. The lifecycle vocabulary consists of five normative states: Init, Active, Transformed, Retired, and Zeroized. Each state reflects the semantic condition of an SDLP object at a specific point in its lifecycle. States are descriptive only; they do not modify DigitalID, InstanceID, Lineage, Timestamp, or Body. 3.1. Init The Init state represents the creation of the first SDLP object in a lifecycle. Init establishes the immutable DigitalID and initializes InstanceID and Lineage to their canonical starting values. Objects in Init state have no parent and serve as the root of all subsequent lifecycle transitions. Init objects MUST: * define the initial DigitalID (Identity-02), * set InstanceID := "1", * set Lineage := "1", * record a unique Timestamp, * encode Body canonically according to Object-Format-08. 3.2. Active The Active state represents an SDLP object that is currently valid, usable, and capable of undergoing further lifecycle transitions. Active objects serve as parents for Transform, Retire, and Zeroize transitions. Active objects MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp per transition, * maintain canonical envelope encoding. 3.3. Transformed The Transformed state represents an SDLP object produced by a Transform transition. Transformation creates a new child object whose Body differs from its parent while preserving identity and extending ancestry. Transformed objects MUST: * inherit DigitalID from the parent, * extend InstanceID by appending "." ChildIndex, * extend Lineage by appending "." ChildIndex, * record a unique Timestamp, * encode the new Body canonically. Transformed objects remain Active unless subsequently Retired or Zeroized. 3.4. Retired The Retired state represents an SDLP object that is no longer active and MUST NOT undergo further transitions. Retirement is a terminal lifecycle condition indicating that the object has completed its intended purpose. Retired objects MUST: * preserve DigitalID exactly, * extend InstanceID and Lineage deterministically, * record a unique Timestamp, * encode Body canonically, * be treated as terminal by all relying parties. Retired objects remain valid for provenance and verification but cannot serve as parents for new transitions. 3.5. Zeroized The Zeroized state represents an SDLP object produced by a Zeroize transition. Zeroization is a terminal lifecycle condition indicating that the object has been cryptographically or operationally rendered inert. Zeroized objects MUST: * preserve DigitalID exactly, * extend InstanceID and Lineage deterministically, * record a unique Timestamp, * encode Body canonically (typically empty or null-equivalent), * be treated as terminal by all relying parties. Zeroized objects MUST NOT undergo further transitions and MUST be treated as final lifecycle artifacts. 3.6. State Inference Lifecycle states are inferred from the transition class used to produce the object. Implementations MUST NOT attempt to encode state directly in the canonical envelope. State inference MUST follow: * Init → produced by Init transition * Active → produced by Init or Transform transitions * Transformed→ produced by Transform transition * Retired → produced by Retire transition * Zeroized → produced by Zeroize transition State inference MUST be deterministic and MUST NOT rely on metadata outside the canonical envelope. 3.7. State Validity A relying party MUST reject any SDLP object whose inferred state violates canonical lifecycle semantics, including: * invalid transition ordering, * malformed ancestry, * incorrect InstanceID or Lineage growth, * reuse of Timestamp, * non-canonical envelope encoding. State validity is a normative requirement for SDLP interoperability. 4. Transition Rules This section defines the normative rules governing SDLP lifecycle transitions. Each transition produces a new SDLP object whose DigitalID, InstanceID, Lineage, Timestamp, and Body conform to the canonical grammar defined in Object-Format-08. Transitions MUST be deterministic, MUST NOT rewrite parent objects, and MUST preserve identity and ancestry according to Identity-02 and Lineage-03. All transitions share the following invariants: * DigitalID is immutable and preserved byte-for-byte. * InstanceID extends deterministically by appending "." ChildIndex. * Lineage extends deterministically by appending "." ChildIndex. * Timestamp records the exact moment of creation and MUST NOT be reused. * Body is encoded canonically as unpadded base64url of raw bytes. * The canonical envelope MUST contain exactly five fields and four LF separators. A relying party MUST reject any transition that violates these rules. 4.1. Init Transition The Init transition creates the first SDLP object in a lifecycle. Init establishes the immutable DigitalID and initializes InstanceID and Lineage to their canonical starting values. Init MUST: * generate a new DigitalID according to Identity-02, * set InstanceID := "1", * set Lineage := "1", * record a unique Timestamp, * encode Body canonically, * produce a canonical envelope conforming to Object-Format-08. Init objects have no parent and serve as the root of all subsequent lifecycle transitions. 4.2. Activate Transition The Activate transition moves an object from Init to Active state. Activation does not modify Body; it establishes the object as eligible for future Transform, Retire, or Zeroize transitions. Activate MUST: * preserve DigitalID exactly, * extend InstanceID := Parent.InstanceID "." ChildIndex, * extend Lineage := Parent.Lineage "." ChildIndex, * record a unique Timestamp, * preserve Body exactly as provided by the parent, * produce a canonical envelope. Activate transitions MUST NOT modify the parent object. 4.3. Transform Transition The Transform transition produces a new child object whose Body differs from its parent while preserving identity and extending ancestry. Transform is the primary mechanism for evolving content while maintaining provenance continuity. Transform MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode the new Body canonically, * produce a canonical envelope. Transform MUST NOT: * rewrite the parent object, * truncate or reorder ancestry, * reuse Timestamp, * modify DigitalID. 4.4. Retire Transition The Retire transition produces a terminal SDLP object that MUST NOT undergo further transitions. Retirement indicates that the object has completed its intended purpose. Retire MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode Body canonically, * produce a canonical envelope. Retired objects remain valid for provenance and verification but are terminal lifecycle artifacts. 4.5. Zeroize Transition The Zeroize transition produces a terminal SDLP object that has been cryptographically or operationally rendered inert. Zeroization is a stronger terminal condition than Retire and is used when an object must be invalidated or decommissioned. Zeroize MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode Body canonically (typically empty or null-equivalent), * produce a canonical envelope. Zeroized objects MUST NOT undergo further transitions and MUST be treated as final lifecycle artifacts. 4.6. ChildIndex Rules ChildIndex is a positive integer appended to InstanceID and Lineage during each transition. ChildIndex MUST satisfy: * ChildIndex is a positive integer (1, 2, 3, ...), * ChildIndex is unique among siblings, * ChildIndex MUST NOT be reused, * ChildIndex MUST reflect deterministic ordering. A relying party MUST reject any object whose ChildIndex violates these rules. 4.7. Transition Ordering Lifecycle transitions MUST follow the canonical ordering: * Init → Activate → Transform → Retire → Zeroize Transform MAY occur multiple times. Retire and Zeroize are terminal and MUST NOT be followed by additional transitions. A relying party MUST reject any object whose inferred transition ordering violates canonical lifecycle semantics. 4.8. Transition Validity A transition is valid only if: * DigitalID is preserved exactly, * InstanceID and Lineage extend deterministically, * Timestamp is unique and well-formed, * Body is encoded canonically, * the canonical envelope is well-formed, * no prohibited fields or metadata are present. Any violation constitutes a lifecycle error and MUST cause the object to be rejected. 5. Canonical Transition Grammar This section defines the normative grammar for SDLP lifecycle transitions. The grammar specifies how DigitalID, InstanceID, Lineage, Timestamp, and Body MUST be constructed during each transition. All SDLP implementations MUST follow this grammar exactly to ensure deterministic lifecycle evolution and interoperable validation. Canonical transition grammar is applied before hashing, signing, or validation. Any deviation from this grammar constitutes a lifecycle violation and MUST cause the object to be rejected. 5.1. Canonical Envelope Structure All lifecycle transitions MUST produce a canonical envelope conforming to Object-Format-08: DigitalID LF InstanceID LF Lineage LF Timestamp LF Body Where: * LF is U+000A, * all fields are UTF-8 encoded, * Body is unpadded base64url of raw bytes, * no optional fields, whitespace, or metadata are permitted. The canonical envelope is the hashing and signing preimage for all SDLP objects. 5.2. DigitalID Grammar DigitalID is defined in Identity-02 and MUST be preserved exactly across all transitions. DigitalID MUST satisfy: DigitalID := 1*base64url DigitalID MUST NOT be rewritten, truncated, substituted, or modified during any lifecycle transition. 5.3. InstanceID Grammar InstanceID is a hierarchical lifecycle index. InstanceID MUST satisfy: InstanceID := "1" / (InstanceID "." ChildIndex) ChildIndex := 1*DIGIT ; positive integer, no leading zeros Rules: * Init sets InstanceID := "1". * Each transition appends "." ChildIndex. * ChildIndex MUST be unique among siblings. * ChildIndex MUST NOT be reused. * ChildIndex MUST reflect deterministic ordering. A relying party MUST reject any InstanceID that violates this grammar. 5.4. Lineage Grammar Lineage reflects complete ancestry and MUST satisfy: Lineage := "1" / (Lineage "." ChildIndex) Rules: * Init sets Lineage := "1". * Each transition appends "." ChildIndex. * Lineage MUST grow deterministically with InstanceID. * Lineage MUST NOT be truncated, reordered, or rewritten. Lineage MUST match InstanceID growth exactly. Any mismatch constitutes a BitDrop event and MUST be rejected. 5.5. Timestamp Grammar Timestamp MUST satisfy: Timestamp := YYYY "-" MM "-" DD "T" HH ":" MM ":" SS Where: * YYYY is a four-digit year, * MM, DD, HH, MM, SS are two-digit zero-padded integers, * no timezone suffix is permitted, * Timestamp MUST be unique per transition. Timestamp MUST NOT be reused or modified after object creation. 5.6. Body Grammar Body MUST satisfy: Body := 1*base64url Rules: * Body is unpadded base64url of raw bytes, * Body MUST be canonical, * Body MUST NOT contain whitespace, padding, or metadata, * Body MUST reflect the exact raw bytes of the object’s content. Transform transitions produce a new Body; other transitions MAY preserve the parent Body. 5.7. Transition Grammar Summary Each lifecycle transition MUST produce: DigitalID' = DigitalID(parent) InstanceID' = InstanceID(parent) "." ChildIndex Lineage' = Lineage(parent) "." ChildIndex Timestamp' = unique timestamp Body' = canonical base64url Init is the only transition that does not use a parent: DigitalID' = new DigitalID InstanceID' = "1" Lineage' = "1" Timestamp' = unique timestamp Body' = canonical base64url 5.8. Canonical Grammar Enforcement A relying party MUST enforce canonical grammar before: * hashing, * signing, * lifecycle validation, * provenance analysis, * interoperability processing. Any violation of canonical grammar MUST cause the object to be rejected, logged, and surfaced to policy. Canonical grammar is a security-critical component of SDLP lifecycle semantics and MUST be implemented consistently across all SDLP-aware systems. 6. Transition Classes (Normative) Transition classes define the normative semantics governing how SDLP objects evolve during lifecycle transitions. Each transition class specifies how DigitalID, InstanceID, Lineage, Timestamp, and Body MUST be constructed. Transition classes are normative and MUST be enforced by all SDLP implementations. Transition classes do not appear in the canonical envelope; they are inferred from the structure of InstanceID and Lineage and from the semantics of the transition that produced the object. The SDLP lifecycle defines five transition classes: * Init * Activate * Transform * Retire * Zeroize Each class is described in the following sections. 6.1. Init Class The Init class defines the creation of the first SDLP object in a lifecycle. Init establishes the immutable DigitalID and initializes InstanceID and Lineage to their canonical starting values. Init MUST: * generate a new DigitalID according to Identity-02, * set InstanceID := "1", * set Lineage := "1", * record a unique Timestamp, * encode Body canonically according to Object-Format-08. Init MUST NOT: * reuse any DigitalID, * derive DigitalID from a parent object, * reuse Timestamp, * include optional metadata. 6.2. Activate Class The Activate class transitions an object from Init to Active state. Activation does not modify Body; it establishes the object as eligible for future Transform, Retire, or Zeroize transitions. Activate MUST: * preserve DigitalID exactly, * extend InstanceID := Parent.InstanceID "." ChildIndex, * extend Lineage := Parent.Lineage "." ChildIndex, * record a unique Timestamp, * preserve Body exactly as provided by the parent. Activate MUST NOT: * modify Body, * rewrite DigitalID, * truncate or reorder ancestry, * reuse ChildIndex. 6.3. Transform Class The Transform class produces a new child object whose Body differs from its parent while preserving identity and extending ancestry. Transform is the primary mechanism for evolving content while maintaining provenance continuity. Transform MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode the new Body canonically. Transform MUST NOT: * rewrite the parent object, * reuse Timestamp, * modify DigitalID, * truncate or reorder ancestry. 6.4. Retire Class The Retire class produces a terminal SDLP object that MUST NOT undergo further transitions. Retirement indicates that the object has completed its intended purpose. Retire MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode Body canonically. Retire MUST NOT: * serve as a parent for any future transition, * modify DigitalID, * reuse Timestamp, * alter parent Body. 6.5. Zeroize Class The Zeroize class produces a terminal SDLP object that has been cryptographically or operationally rendered inert. Zeroization is a stronger terminal condition than Retire. Zeroize MUST: * preserve DigitalID exactly, * extend InstanceID deterministically, * extend Lineage deterministically, * record a unique Timestamp, * encode Body canonically (typically empty or null-equivalent). Zeroize MUST NOT: * serve as a parent for any future transition, * modify DigitalID, * reuse Timestamp, * include non-canonical metadata. 6.6. Transition Class Inference Transition classes are inferred from the semantics of the transition and MUST NOT be encoded directly in the canonical envelope. Inference MUST follow: * Init → produced by Init transition * Activate → produced by Activate transition * Transform → produced by Transform transition * Retire → produced by Retire transition * Zeroize → produced by Zeroize transition A relying party MUST reject any object whose inferred transition class violates canonical lifecycle semantics. 6.7. Transition Class Validity A transition class is valid only if: * DigitalID is preserved exactly, * InstanceID and Lineage extend deterministically, * Timestamp is unique and well-formed, * Body is canonical, * the canonical envelope is well-formed, * no prohibited metadata is present. Any violation constitutes a lifecycle error and MUST cause the object to be rejected. 7. Lifecycle Validation Rules This section defines the normative validation requirements for SDLP lifecycle processing. A relying party MUST apply these validation rules before accepting any SDLP object as canonical, trustworthy, or interoperable. Validation MUST be deterministic, byte-for-byte, and MUST NOT rely on external metadata or contextual inference. Lifecycle validation ensures that DigitalID, InstanceID, Lineage, Timestamp, and Body conform to canonical grammar and that the object was produced by a valid lifecycle transition. 7.1. Canonical Envelope Validation A relying party MUST validate that the SDLP object conforms to the canonical envelope defined in Object-Format-08: * exactly five fields, * exactly four LF separators, * UTF-8 encoding, * no trailing whitespace, * no optional metadata, * Body encoded as unpadded base64url. Any deviation constitutes a canonical envelope error and MUST cause the object to be rejected. 7.2. DigitalID Validation DigitalID MUST be validated according to Identity-02: * DigitalID MUST be present, * DigitalID MUST be syntactically valid base64url, * DigitalID MUST NOT change across transitions, * DigitalID MUST match the parent DigitalID exactly. A relying party MUST reject any object whose DigitalID differs from its parent or violates Identity-02. 7.3. InstanceID Validation InstanceID MUST be validated according to Lifecycle-03: * InstanceID MUST be syntactically valid, * InstanceID MUST begin with "1", * each segment MUST be a positive integer with no leading zeros, * ChildIndex MUST be unique among siblings, * ChildIndex MUST NOT be reused, * InstanceID MUST grow deterministically. Any violation constitutes an InstanceID error and MUST cause the object to be rejected. 7.4. Lineage Validation Lineage MUST be validated according to Lineage-03: * Lineage MUST begin with "1", * Lineage MUST grow deterministically with InstanceID, * Lineage MUST NOT be truncated, reordered, or rewritten, * Lineage MUST match InstanceID growth exactly. A mismatch between InstanceID and Lineage constitutes a BitDrop event and MUST cause the object to be rejected. 7.5. Timestamp Validation Timestamp MUST be validated according to canonical grammar: * Timestamp MUST match YYYY-MM-DD "T" HH:MM:SS, * Timestamp MUST be unique per transition, * Timestamp MUST NOT be reused, * Timestamp MUST NOT include timezone suffixes. A relying party MUST reject any object with a malformed or reused Timestamp. 7.6. Body Validation Body MUST be validated according to Object-Format-08: * Body MUST be unpadded base64url, * Body MUST decode to raw bytes without error, * Body MUST NOT contain whitespace or metadata, * Body MUST reflect the exact raw bytes of the object’s content. Transform transitions MUST produce a new Body; other transitions MAY preserve the parent Body. 7.7. Transition Validation A relying party MUST validate that the object was produced by a valid lifecycle transition: * Init MUST have no parent, * Activate MUST preserve Body, * Transform MUST modify Body, * Retire MUST be terminal, * Zeroize MUST be terminal and inert. Transition ordering MUST follow: Init → Activate → Transform → Retire → Zeroize Any violation constitutes a transition error and MUST cause the object to be rejected. 7.8. Parent-Child Consistency Validation For all transitions except Init, a relying party MUST validate: * DigitalID(parent) == DigitalID(child), * InstanceID(child) extends InstanceID(parent), * Lineage(child) extends Lineage(parent), * ChildIndex is unique and valid, * Timestamp(child) is strictly greater than Timestamp(parent), * Body(child) is canonical. Any inconsistency constitutes a lifecycle violation. 7.9. Terminal State Validation Retired and Zeroized objects MUST be validated as terminal: * they MUST NOT serve as parents, * they MUST NOT undergo further transitions, * they MUST remain valid for provenance and verification. A relying party MUST reject any object that attempts to extend a terminal object. 7.10. Validation Failure Handling If any validation rule fails, the relying party MUST: * reject the object, * record the failure, * surface the failure to policy, * treat the object as non-canonical and non-interoperable. Validation failures MUST NOT be silently ignored. 7.11. Deterministic Validation Requirement Lifecycle validation MUST be deterministic: * identical inputs MUST produce identical validation results, * validation MUST NOT depend on external metadata, * validation MUST NOT depend on system time, * validation MUST NOT depend on implementation-specific behavior. Deterministic validation is required for interoperability across all SDLP-aware systems. 8. Security Considerations SDLP lifecycle semantics are security‑critical. Incorrect lifecycle processing can result in identity substitution, lineage truncation, timestamp reuse, or other forms of BitDrop that compromise provenance integrity. Implementations MUST apply strict validation rules to ensure that DigitalID, InstanceID, Lineage, Timestamp, and Body conform to canonical grammar and that all lifecycle transitions are valid. 8.1. Identity Preservation DigitalID is immutable and MUST be preserved byte‑for‑byte across all transitions. Any modification, substitution, truncation, or rewriting of DigitalID constitutes an identity violation. A relying party MUST reject any object whose DigitalID differs from its parent. Identity substitution attacks include: * replacing DigitalID with a forged value, * injecting a DigitalID from a different lifecycle, * truncating or padding DigitalID, * re‑encoding DigitalID using non‑canonical base64url. These attacks MUST be detected and rejected. 8.2. Ancestry Integrity Lineage and InstanceID MUST grow deterministically and MUST match exactly. Any mismatch constitutes a BitDrop event and MUST be rejected as a security violation. Ancestry attacks include: * truncating lineage segments, * reordering lineage segments, * reusing ChildIndex values, * inserting synthetic ancestors, * removing legitimate ancestors. These attacks compromise provenance and MUST be rejected. 8.3. Timestamp Integrity Timestamp reuse enables replay attacks, lifecycle confusion, and provenance ambiguity. Timestamp MUST be unique per transition and MUST conform to canonical grammar. Timestamp attacks include: * reusing timestamps across transitions, * forging timestamps outside canonical format, * inserting timezone suffixes, * manipulating timestamps to alter lifecycle ordering. Relying parties MUST reject any object with a malformed or reused timestamp. 8.4. Canonical Envelope Integrity The canonical envelope is the hashing and signing preimage for all SDLP objects. Any deviation from canonical envelope grammar MUST be treated as a security violation. Envelope attacks include: * inserting whitespace or metadata, * adding optional fields, * altering LF separators, * re‑encoding Body using padded base64url, * injecting non‑canonical UTF‑8 sequences. These attacks MUST be rejected before hashing or signature validation. 8.5. Body Integrity Body contains the raw bytes of the SDLP object’s content. Body MUST be encoded as unpadded base64url and MUST NOT be modified except during Transform transitions. Body attacks include: * rewriting Body outside Transform, * injecting metadata into Body, * encoding Body using padded base64url, * substituting Body with unrelated content. Relying parties MUST reject any object whose Body violates canonical grammar. 8.6. Terminal State Enforcement Retired and Zeroized objects are terminal and MUST NOT serve as parents for further transitions. Allowing terminal objects to be extended enables lifecycle confusion, provenance corruption, and unauthorized object resurrection. Terminal state attacks include: * extending Retired objects, * extending Zeroized objects, * treating terminal objects as Active. These attacks MUST be rejected. 8.7. Deterministic Validation Lifecycle validation MUST be deterministic. Non‑deterministic validation enables inconsistent interpretation of SDLP objects across relying parties, creating opportunities for downgrade attacks, inconsistent provenance, and signature confusion. Deterministic validation requires: * byte‑for‑byte canonicalization, * strict grammar enforcement, * consistent ancestry interpretation, * rejection of non‑canonical envelopes. 8.8. Interoperability and Security Lifecycle‑03, Identity‑02, Lineage‑03, and Object‑Format‑08 form a unified security model. Implementations MUST enforce all four specifications together. Partial enforcement enables downgrade attacks, inconsistent ancestry interpretation, and non‑canonical object acceptance. Relying parties MUST treat any violation of canonical grammar, lifecycle semantics, or transition rules as a security failure. 8.9. Logging and Policy Implementations SHOULD log lifecycle validation failures and SHOULD surface them to policy. Logging enables detection of: * repeated BitDrop attempts, * identity substitution attempts, * timestamp reuse, * non‑canonical envelope injection, * unauthorized terminal state extension. Logs SHOULD NOT contain raw Body bytes unless required by policy. Lifecycle validation failures MUST NOT be silently ignored. 9. IANA Considerations This document has no IANA actions. No registries are created, modified, or deprecated by this specification. SDLP lifecycle semantics, canonical grammar, and transition rules do not require protocol parameters or registry assignments. Implementations MUST NOT attempt to register SDLP lifecycle identifiers, transition classes, or canonical envelope fields with IANA. 10. Normative References [Identity-02] Norton, M., "SDLP Identity Specification", draft-norton-sdlp-identity-02, August 2026. [Lineage-03] Norton, M., "SDLP Lineage Specification", draft-norton-sdlp-lineage-03, August 2026. [Obj-Format-08] Norton, M., "SDLP Object Format Specification", draft-norton-sdlp-obj-format-08, August 2026. [Lifecycle-03] Norton, M., "SDLP Lifecycle Specification", draft-norton-sdlp-lifecycle-03, August 2026. [Sec-Arch-04] Norton, M., "SDLP Security Architecture", draft-norton-sdlp-sec-arch-04, August 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 11. Informative References [Interop-Profile-04] Norton, M., "SDLP Interoperability Profile", draft-norton-sdlp-interop-profile-04, August 2026. [Fixture-Bundle-v4] Norton, M., "SDLP Fixture Bundle v4", https://github.com/MightyRighty1/SDLP/releases/tag/v4, 2026. [Architecture-03] Norton, M., "SDLP Architecture Overview", draft-norton-sdlp-arch-03, July 2026. [Overview-01] Norton, M., "SDLP Overview", draft-norton-sdlp-overview-01, July 2026. [Physics-00] Norton, M., "SDLP Physics Model", draft-norton-sdlp-physics-00, July 2026. [Provenance-Research] Various Authors, "Research in Digital Provenance and Content Authenticity", ACM, IEEE, and related venues. 12. Acknowledgments The author thanks Iman for her assistance in preparing and validating the fixture-bundle-v4 reference set. Her review and feedback improved the clarity and consistency of the lifecycle examples used throughout this document. Appendix A. Canonical Lifecycle Example (Informative) This appendix provides an illustrative example of a complete SDLP lifecycle. The example demonstrates canonical envelope encoding, deterministic InstanceID and Lineage growth, valid transition ordering, and correct application of lifecycle semantics. The example uses placeholder values for DigitalID, Timestamp, and Body. These values are for demonstration only and do not represent actual SDLP fixture data. A.1. Init (Root Object) The Init transition creates the first SDLP object in the lifecycle. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1 Lineage: 1 Timestamp: 2026-08-05T10:15:00 Body: VGhpcyBpcyB0aGUgaW5pdCBvYmplY3Qu Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1 1 2026-08-05T10:15:00 VGhpcyBpcyB0aGUgaW5pdCBvYmplY3Qu A.2. Activate (Object Becomes Active) Activation preserves Body and extends ancestry deterministically. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1.1 Lineage: 1.1 Timestamp: 2026-08-05T10:15:05 Body: VGhpcyBpcyB0aGUgaW5pdCBvYmplY3Qu Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1.1 1.1 2026-08-05T10:15:05 VGhpcyBpcyB0aGUgaW5pdCBvYmplY3Qu A.3. Transform (Content Evolution) Transform produces a new Body while preserving identity and extending ancestry. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1.1.1 Lineage: 1.1.1 Timestamp: 2026-08-05T10:16:00 Body: VXBkYXRlZCBjb250ZW50IGFmdGVyIHRyYW5zZm9ybS4= Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1.1.1 1.1.1 2026-08-05T10:16:00 VXBkYXRlZCBjb250ZW50IGFmdGVyIHRyYW5zZm9ybS4= A.4. Transform (Second Evolution) A second Transform demonstrates repeated content evolution. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1.1.1.1 Lineage: 1.1.1.1 Timestamp: 2026-08-05T10:17:30 Body: U2Vjb25kIHRyYW5zZm9ybSB1cGRhdGUu Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1.1.1.1 1.1.1.1 2026-08-05T10:17:30 U2Vjb25kIHRyYW5zZm9ybSB1cGRhdGUu A.5. Retire (Terminal Object) Retire produces a terminal object that MUST NOT undergo further transitions. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1.1.1.1.1 Lineage: 1.1.1.1.1 Timestamp: 2026-08-05T10:18:00 Body: U2Vjb25kIHRyYW5zZm9ybSB1cGRhdGUu Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1.1.1.1.1 1.1.1.1.1 2026-08-05T10:18:00 U2Vjb25kIHRyYW5zZm9ybSB1cGRhdGUu A.6. Zeroize (Final Terminal Object) Zeroize renders the object inert and concludes the lifecycle. DigitalID: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 InstanceID: 1.1.1.1.1.1 Lineage: 1.1.1.1.1.1 Timestamp: 2026-08-05T10:18:30 Body: (empty) Canonical Envelope: AbCdEfGhIjKlMnOpQrStUvWxYz1234567890 1.1.1.1.1.1 1.1.1.1.1.1 2026-08-05T10:18:30 Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com