Internet-Draft M. Norton Intended status: Informational Independent Expires: January 27, 2027 July 27, 2026 SDLP RFC 2: Lifecycle Specification draft-norton-sdlp-lifecycle-02 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com July 2026 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Abstract This document defines the lifecycle model for the Secured Digital Lifecycle Protocol (SDLP). The lifecycle model specifies the canonical state machine used by all SDLP-governed objects, including the rules for state transitions, transformation events, duplication events, and materialization events. The lifecycle model provides a stable and predictable framework for describing how SDLP objects evolve over time while preserving identity, lineage, and security guarantees defined in companion SDLP specifications. This document updates and formalizes the lifecycle semantics originally introduced in draft-norton-sdlp-lifecycle-00. 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines a unified provenance, identity, and lifecycle framework for digital objects. Lifecycle-01 introduced the initial lifecycle model, including preliminary definitions of object states, transition types, and lineage behavior. Subsequent review identified inconsistencies across the SDLP suite—particularly in Identity-01, Object-Format-01, and early lineage semantics—that required a normative revision. Lifecycle-02 provides the authoritative definition of the SDLP lifecycle model. It formalizes the canonical state machine used by all SDLP-governed objects, including the rules for duplication, derivation, transformation, and materialization events. This document supersedes Lifecycle-01 and resolves cross-draft contradictions identified during interoperability analysis and early implementer feedback. The lifecycle model defined in this document establishes how SDLP objects evolve over time while preserving the immutable DigitalID defined in draft-norton-sdlp-identity-02. All compliant implementations MUST treat the lifecycle semantics described herein as normative. All other SDLP specifications—including Identity, Lineage, Object Format, Physics, and Security—MUST reference this document when defining lifecycle-related behavior. Lifecycle-02 ensures: * deterministic and predictable state transitions, * stable identity inheritance across all transitions, * consistent lineage extension rules, * interoperability with SCITT, EMILIA, and external provenance systems, * clear separation between identity, lineage, and lifecycle semantics. This document updates and formalizes the lifecycle semantics originally introduced in draft-norton-sdlp-lifecycle-00 and refined in draft-norton-sdlp-lifecycle-01. 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 referenced here for completeness. State: A lifecycle condition of an SDLP object. States are defined normatively in Section 3 and represent the canonical positions an object may occupy within the lifecycle model. Transition: A lifecycle event that moves an object from one state to another. Transitions are atomic, deterministic, and governed by the rules defined in this document. Origin Object: The first object created during an acquisition or provisioning event. The origin object receives the initial DigitalID, InstanceID, Lineage, and Timestamp. DigitalID: The immutable identity tuple defined in draft-norton-sdlp-identity-02. DigitalID uniquely identifies the origin object and is inherited unchanged by all descendants. InstanceID: A per-object identifier assigned at each lifecycle transition. InstanceID is not part of DigitalID and may change as objects are copied, derived, or transformed. Lineage: A structured record of parent-child relationships formed through lifecycle transitions. Lineage is not part of DigitalID and grows deterministically as transitions occur. Timestamp: The Date and Time associated with a lifecycle transition. Timestamp reflects the moment the transition occurred and is distinct from the immutable Date and Time fields in DigitalID. Duplication: A transition that produces a bitwise-identical copy of an object. Duplication assigns a new InstanceID, extends Lineage, and records a new Timestamp. Derivation: A transition that produces a new object whose content is derived from, but not identical to, the parent object. Derivation assigns a new InstanceID, extends Lineage, and records a new Timestamp. Transformation: A transition that alters the representation, encoding, or format of an object while preserving its semantic content. Transformation assigns a new InstanceID, extends Lineage, and records a new Timestamp. Materialization: A transition that produces a physical or alternative-format manifestation of an object (e.g., rendering, printing, packaging). Materialization assigns a new InstanceID, extends Lineage, and records a new Timestamp. Destruction: A terminal transition that marks an object as no longer active or usable. Destruction does not modify DigitalID but finalizes the object’s lifecycle. Canonical Representation: The normative byte-level representation of an object used for hashing, signing, and lifecycle validation. Canonical representation rules are defined in SDLP Object Format. Parent Object: The object from which a child object is produced during a lifecycle transition. Child Object: The object produced by a lifecycle transition. Child objects inherit the parent DigitalID unchanged and receive new InstanceID, Lineage, and Timestamp values. Relying Party: Any system that consumes SDLP objects and performs validation, verification, or admission decisions based on lifecycle and identity information. 3. Lifecycle State Vocabulary (Normative) This section defines the canonical lifecycle state vocabulary for all SDLP-governed objects. States represent the normative positions an object may occupy within the lifecycle model. Transitions represent the deterministic events that move an object from one state to another. All SDLP-compliant implementations MUST support the full state vocabulary and transition classes defined in this section. No additional states or transitions may be introduced without updating this specification. 3.1. State Overview SDLP defines the following canonical states: ORIGIN ACTIVE COPIED DERIVED TRANSFORMED MATERIALIZED FINAL These states form the complete lifecycle model. Every SDLP object MUST occupy exactly one of these states at any given time. 3.2. ORIGIN State ORIGIN is the initial state of an SDLP object. An object enters the ORIGIN state when it is first created during an acquisition or provisioning event. Objects in the ORIGIN state receive: * DigitalID (immutable) * InstanceID = 1 * Lineage = 1 * Timestamp corresponding to the assignment moment An object MUST leave the ORIGIN state before any lifecycle transition other than activation. 3.3. ACTIVE State ACTIVE represents an object that is available for use, processing, duplication, derivation, or transformation. ACTIVE is the baseline operational state for all SDLP objects. An object enters ACTIVE immediately after ORIGIN or after any transition that produces a new child object. ACTIVE is the only state from which duplication, derivation, transformation, or materialization transitions may occur. 3.4. COPIED State COPIED represents an object produced through a duplication transition. A COPIED object is bitwise-identical to its parent. A COPIED object receives: * The parent DigitalID (unchanged) * A new InstanceID * Extended Lineage * A new Timestamp After creation, a COPIED object immediately enters the ACTIVE state. 3.5. DERIVED State DERIVED represents an object produced through a derivation transition. A DERIVED object is not bitwise-identical to its parent but is semantically related. A DERIVED object receives: * The parent DigitalID (unchanged) * A new InstanceID * Extended Lineage * A new Timestamp After creation, a DERIVED object immediately enters the ACTIVE state. 3.6. TRANSFORMED State TRANSFORMED represents an object produced through a transformation transition. A TRANSFORMED object preserves the semantic content of its parent but changes its representation, encoding, or format. A TRANSFORMED object receives: * The parent DigitalID (unchanged) * A new InstanceID * Extended Lineage * A new Timestamp After creation, a TRANSFORMED object immediately enters the ACTIVE state. 3.7. MATERIALIZED State MATERIALIZED represents an object produced through a materialization transition. Materialization produces a physical or alternative-format manifestation of an object (e.g., rendering, printing, packaging). A MATERIALIZED object receives: * The parent DigitalID (unchanged) * A new InstanceID * Extended Lineage * A new Timestamp After creation, a MATERIALIZED object may enter ACTIVE or FINAL depending on implementation policy. 3.8. FINAL State FINAL represents an object that has completed its lifecycle. Objects in the FINAL state are no longer active and may not undergo further transitions. FINAL is typically reached through a destruction transition or through policy-driven lifecycle completion. 3.9. Transition Classes SDLP defines the following normative transition classes: Duplication Transition Derivation Transition Transformation Transition Materialization Transition Destruction Transition Each transition class: * produces a child object, * assigns a new InstanceID, * extends Lineage, * records a new Timestamp, * preserves DigitalID exactly. Transition rules are defined in Section 4. 3.10. State Machine Summary The canonical lifecycle state machine is: ORIGIN → ACTIVE → {COPIED, DERIVED, TRANSFORMED, MATERIALIZED} → ACTIVE → FINAL All SDLP objects MUST follow this state machine. No other state progressions are permitted. 4. Transition Rules This section defines the normative rules governing all SDLP lifecycle transitions. A transition is an atomic event that produces a child object from a parent object. All transitions MUST preserve the parent DigitalID exactly and MUST assign new InstanceID, Lineage, and Timestamp values according to the rules defined in this section. Transitions are deterministic: given the same parent object and the same transition type, all compliant implementations MUST produce the same identity-related results. 4.1. Transition Preconditions A lifecycle transition MAY occur only when: * the parent object is in the ACTIVE state, * the parent object has a valid DigitalID (Identity-02), * the parent object has a valid InstanceID and Lineage, * the parent object has a canonical representation (Object Format), * the transition type is permitted by the state machine (Section 3). Implementations MUST reject transitions that violate these preconditions. 4.2. Identity Inheritance All transitions MUST preserve the DigitalID of the parent object exactly. The child object inherits: * DigitalID (unchanged), * a new InstanceID, * an extended Lineage value, * a new Timestamp corresponding to the transition moment. DigitalID MUST NOT be regenerated, replaced, or modified during any transition. 4.3. InstanceID Assignment Each transition MUST assign a new InstanceID to the child object. InstanceID assignment MUST follow the deterministic grammar defined in SDLP Lineage: parent InstanceID + "." + child index Examples: 1 → 1.1 1.1 → 1.1.1 2.3.4 → 2.3.4.1 InstanceID MUST be unique among siblings produced by the same parent. 4.4. Lineage Extension Each transition MUST extend the parent’s Lineage value according to the lineage grammar defined in SDLP Lineage. Lineage extension MUST be deterministic and MUST reflect the parent-child relationship created by the transition. Lineage MUST NOT be truncated, rewritten, or replaced. 4.5. Timestamp Assignment Each transition MUST assign a new Timestamp to the child object. The Timestamp MUST reflect the moment the transition occurred and MUST be expressed in: * Date: YYYY-MM-DD * Time: HH:MM:SS (24-hour format) Timestamp is distinct from the immutable Date and Time fields in DigitalID. 4.6. Duplication Transition A duplication transition produces a bitwise-identical child object. Duplication MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage, * assign a new Timestamp, * produce a child object whose canonical representation is identical to the parent. The child object enters the COPIED state and then immediately enters ACTIVE. 4.7. Derivation Transition A derivation transition produces a child object whose content is derived from, but not identical to, the parent. Derivation MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage, * assign a new Timestamp, * produce a child object whose canonical representation differs from the parent. The child object enters the DERIVED state and then immediately enters ACTIVE. 4.8. Transformation Transition A transformation transition produces a child object whose semantic content is preserved but whose representation, encoding, or format is changed. Transformation MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage, * assign a new Timestamp, * produce a child object whose canonical representation differs from the parent but whose semantic content is equivalent. The child object enters the TRANSFORMED state and then immediately enters ACTIVE. 4.9. Materialization Transition A materialization transition produces a physical or alternative-format manifestation of an object (e.g., rendering, printing, packaging). Materialization MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage, * assign a new Timestamp, * produce a child object whose representation is materially distinct from the parent. The child object enters the MATERIALIZED state and then enters ACTIVE or FINAL depending on implementation policy. 4.10. Destruction Transition A destruction transition marks an object as no longer active or usable. Destruction MUST: * preserve DigitalID exactly, * preserve InstanceID and Lineage, * assign a final Timestamp, * move the object into the FINAL state. Objects in the FINAL state MUST NOT undergo further transitions. 4.11. Transition Validity A transition is valid if and only if: * the parent object is ACTIVE, * the DigitalID is valid (Identity-02), * the transition type is permitted by the state machine, * the child object inherits identity correctly, * the child object receives new InstanceID, Lineage, and Timestamp, * the child object enters the correct state. Invalid transitions MUST be rejected. 5. Canonical Transition Grammar This section defines the canonical grammar governing all SDLP lifecycle transitions. The grammar ensures that transitions are deterministic, reproducible, and interoperable across all compliant implementations. The grammar applies to InstanceID extension, Lineage extension, and Timestamp assignment. All SDLP implementations MUST follow this grammar exactly. Any deviation constitutes a violation of lifecycle semantics. 5.1. Grammar Overview A lifecycle transition is defined as: Transition := Parent → Child where the Child object inherits the parent DigitalID unchanged and receives new values for: * InstanceID * Lineage * Timestamp The canonical grammar for each component is defined below. 5.2. InstanceID Grammar InstanceID MUST follow a hierarchical dot-separated grammar: InstanceID := number *( "." number ) The first InstanceID assigned to an origin object MUST be: 1 A child InstanceID MUST be formed by appending a child index to the parent InstanceID: ChildInstanceID := ParentInstanceID "." ChildIndex ChildIndex MUST begin at 1 for each parent and MUST increment monotonically for each additional child produced by the same parent. Examples: Parent: 1 → Child: 1.1 Parent: 1.1 → Child: 1.1.1 Parent: 2.3.4 → Child: 2.3.4.1 InstanceID MUST be unique among siblings. 5.3. Lineage Grammar Lineage MUST follow the same hierarchical grammar as InstanceID: Lineage := number *( "." number ) Lineage MUST reflect the complete ancestry of the object. A child Lineage MUST be formed by appending a child index to the parent Lineage: ChildLineage := ParentLineage "." ChildIndex Lineage MUST NOT be truncated, rewritten, or replaced. Lineage MUST grow deterministically with each transition. Examples: Parent: 1 → Child: 1.1 Parent: 1.1 → Child: 1.1.1 Parent: 3.2.7 → Child: 3.2.7.1 5.4. Timestamp Grammar Timestamp MUST reflect the moment the transition occurred and MUST be expressed using the following grammar: Date := YYYY "-" MM "-" DD Time := HH ":" MM ":" SS Combined: Timestamp := Date "T" Time Timestamp MUST be assigned at second-level precision or greater. Timestamp MUST NOT reuse the immutable Date and Time fields from DigitalID. 5.5. Transition Grammar A complete transition MUST follow the canonical form: Child.DigitalID = Parent.DigitalID Child.InstanceID = Parent.InstanceID "." ChildIndex Child.Lineage = Parent.Lineage "." ChildIndex Child.Timestamp = CurrentTime where CurrentTime is the Date and Time at the moment the transition occurs. All transition classes (duplication, derivation, transformation, materialization, destruction) MUST follow this grammar. 5.6. Determinism Requirements A transition is deterministic if and only if: * InstanceID is assigned according to Section 5.2, * Lineage is assigned according to Section 5.3, * Timestamp is assigned according to Section 5.4, * DigitalID is preserved exactly. Implementations MUST NOT introduce randomness, optional fields, alternative encodings, or non-canonical formatting. 5.7. Grammar Violations A transition MUST be rejected if: * InstanceID does not follow the canonical grammar, * Lineage does not follow the canonical grammar, * Timestamp is malformed or reused, * DigitalID is modified or regenerated, * ChildIndex is reused or non-monotonic. Grammar violations MUST be surfaced to the relying party or verifier. 6. Transition Classes (Normative) This section defines the normative behavior of each SDLP lifecycle transition class. Transition classes describe the semantic intent of a lifecycle event and determine the state entered by the resulting child object. All transition classes MUST follow the canonical transition grammar defined in Section 5. Each transition class: * produces a child object, * preserves the parent DigitalID exactly, * assigns a new InstanceID, * extends Lineage deterministically, * assigns a new Timestamp, * moves the child object into the correct state. No SDLP-compliant implementation may introduce additional transition classes or modify the semantics defined in this section. 6.1. Duplication Transition A duplication transition produces a bitwise-identical child object. Duplication is used when the parent object is copied without any modification to its canonical representation. Duplication MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage according to Section 5.3, * assign a new Timestamp, * produce a child object whose canonical representation is identical to the parent. The child object enters the COPIED state and then immediately enters ACTIVE. 6.2. Derivation Transition A derivation transition produces a child object whose content is derived from, but not identical to, the parent. Derivation is used when the child object is semantically related to the parent but differs in content, structure, or composition. Derivation MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage according to Section 5.3, * assign a new Timestamp, * produce a child object whose canonical representation differs from the parent. The child object enters the DERIVED state and then immediately enters ACTIVE. 6.3. Transformation Transition A transformation transition produces a child object whose semantic content is preserved but whose representation, encoding, or format is changed. Transformation is used when the object is re-encoded, reformatted, or otherwise altered without changing its meaning. Transformation MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage according to Section 5.3, * assign a new Timestamp, * produce a child object whose canonical representation differs from the parent but whose semantic content is equivalent. The child object enters the TRANSFORMED state and then immediately enters ACTIVE. 6.4. Materialization Transition A materialization transition produces a physical or alternative-format manifestation of an object. Materialization is used when the object is rendered, printed, packaged, or otherwise instantiated in a different modality. Materialization MUST: * preserve DigitalID exactly, * assign a new InstanceID, * extend Lineage according to Section 5.3, * assign a new Timestamp, * produce a child object whose representation is materially distinct from the parent. The child object enters the MATERIALIZED state and then enters ACTIVE or FINAL depending on implementation policy. 6.5. Destruction Transition A destruction transition marks an object as no longer active or usable. Destruction is used when an object is intentionally retired, deleted, invalidated, or otherwise removed from active use. Destruction MUST: * preserve DigitalID exactly, * preserve InstanceID and Lineage, * assign a final Timestamp, * move the object into the FINAL state. Objects in the FINAL state MUST NOT undergo further transitions. 6.6. Transition Class Constraints All transition classes MUST satisfy the following constraints: * The parent object MUST be in the ACTIVE state. * The parent DigitalID MUST be valid (Identity-02). * The child object MUST inherit DigitalID unchanged. * The child object MUST receive new InstanceID, Lineage, and Timestamp values. * The child object MUST enter the correct state defined in Section 3. * The transition MUST follow the canonical grammar in Section 5. Violations of these constraints MUST cause the transition to be rejected. 6.7. Transition Class Summary The canonical transition class mapping is: Duplication → COPIED → ACTIVE Derivation → DERIVED → ACTIVE Transformation → TRANSFORMED → ACTIVE Materialization → MATERIALIZED → ACTIVE | FINAL Destruction → FINAL These mappings are normative and MUST NOT be altered by any SDLP implementation. 7. Lifecycle Validation Rules Lifecycle validation ensures that transitions, state changes, and identity inheritance are performed correctly and consistently across all SDLP implementations. Verifiers, relying parties, and SDLP systems MUST apply the validation procedures described in this section before accepting any lifecycle transition as admissible. Lifecycle validation is required for: * transition sequencing, * state entry correctness, * identity inheritance, * lineage extension, * timestamp assignment, * canonical representation integrity. 7.1. Validation Preconditions A lifecycle transition MUST be validated prior to: * producing a child object, * extending Lineage, * assigning a new InstanceID, * generating signatures or receipts, * admitting the object into a relying party system. Implementations MUST NOT perform lifecycle operations on objects whose DigitalID, InstanceID, or Lineage fail validation. 7.2. State Validation A transition is state-valid if and only if: * the parent object is in the ACTIVE state, * the transition class is permitted from ACTIVE (Section 3), * the resulting child object enters the correct state defined in Section 6. Verifiers MUST reject transitions that: * originate from non-ACTIVE states, * attempt to enter a state not defined in Section 3, * violate the canonical state machine. 7.3. Identity Inheritance Validation A child object MUST inherit the parent DigitalID exactly. Identity inheritance is valid if: * Child.DigitalID == Parent.DigitalID (byte-wise equality), * no DigitalID fields differ, * no DigitalID fields have been regenerated or replaced. Verifiers MUST reject transitions that modify DigitalID in any way. 7.4. InstanceID Validation InstanceID MUST follow the canonical grammar defined in Section 5.2. InstanceID is valid if: * it extends the parent InstanceID by appending "." ChildIndex, * ChildIndex is a positive integer, * ChildIndex is unique among siblings, * the resulting InstanceID conforms to the hierarchical grammar. Verifiers MUST reject InstanceID values that: * reuse a ChildIndex, * skip or reorder indices, * violate the dot-separated grammar, * attempt to rewrite or truncate parent InstanceID. 7.5. Lineage Validation Lineage MUST follow the canonical grammar defined in Section 5.3. Lineage is valid if: * it extends the parent Lineage by appending "." ChildIndex, * it reflects the complete ancestry of the object, * it conforms to the hierarchical grammar. Verifiers MUST reject Lineage values that: * do not extend the parent Lineage, * rewrite or truncate ancestry, * introduce malformed segments, * violate the canonical grammar. 7.6. Timestamp Validation Timestamp MUST follow the grammar defined in Section 5.4. Timestamp is valid if: * Date is in YYYY-MM-DD format, * Time is in HH:MM:SS 24-hour format, * Timestamp reflects the moment of the transition, * Timestamp is not reused from the parent. Verifiers MUST reject Timestamp values that: * reuse the parent Timestamp, * use non-canonical formatting, * contain invalid date or time values. 7.7. Canonical Representation Validation For duplication transitions, the child object MUST be bitwise- identical to the parent. For derivation, transformation, and materialization transitions, the child object MUST differ from the parent in canonical representation. Canonical representation is valid if: * duplication → identical canonical representation, * derivation → different canonical representation, * transformation → different canonical representation but equivalent semantic content, * materialization → materially distinct representation. Verifiers MUST reject transitions whose canonical representation does not match the expected transition class semantics. 7.8. Transition Sequence Validation A transition sequence is valid if: * ORIGIN → ACTIVE is the first transition, * all subsequent transitions originate from ACTIVE, * FINAL is only entered through destruction or policy-driven completion, * no transitions occur after FINAL. Verifiers MUST reject sequences that violate the canonical state machine defined in Section 3. 7.9. Validation Outcomes Lifecycle validation produces one of three outcomes: * VALID: The transition satisfies all structural, identity, lineage, timestamp, and state requirements. * INVALID: The transition violates one or more validation rules. * INDETERMINATE: The verifier cannot determine validity due to missing fields, corrupted encoding, or insufficient information. INVALID transitions MUST be rejected. INDETERMINATE transitions MAY be rejected or deferred based on verifier policy. 7.10. Error Handling When lifecycle validation fails, implementations SHOULD provide: * a clear error code, * a human-readable diagnostic message, * identification of the failing field or rule, * guidance for remediation when possible. Verifiers MUST NOT attempt to repair, reinterpret, or regenerate identity or lineage values. Any such modification violates SDLP lifecycle semantics and MUST be treated as a fatal error. 8. Security Considerations The SDLP lifecycle model defines how objects evolve over time through deterministic transitions. Because lifecycle transitions modify InstanceID, Lineage, Timestamp, and object representation, they are potential targets for tampering, replay, or misuse. This section describes the security considerations associated with lifecycle processing, transition validation, and state machine enforcement. 8.1. Transition Tampering Resistance Lifecycle transitions produce new identity-related values. Any unauthorized modification of InstanceID, Lineage, Timestamp, or canonical representation constitutes transition tampering. Implementations MUST treat as a security violation any transition in which: * InstanceID does not follow the canonical grammar, * Lineage does not extend deterministically, * Timestamp is reused or malformed, * DigitalID is modified, * the resulting state does not match the transition class. Transition metadata SHOULD be included in signed preimages or protected metadata structures to prevent unauthorized modification. 8.2. Lineage Manipulation Lineage reflects the complete ancestry of an object. Manipulating lineage can obscure provenance, hide unauthorized transitions, or misrepresent object history. Verifiers MUST reject objects whose lineage: * truncates ancestry, * rewrites parent segments, * introduces malformed segments, * violates the canonical grammar, * does not correspond to the expected transition class. Lineage MUST be validated before any lifecycle or security operation. 8.3. State Machine Abuse The SDLP state machine defines the only valid progression of object states. An adversary may attempt to bypass or reorder states to conceal unauthorized transitions or force objects into invalid lifecycle positions. Verifiers MUST ensure that: * all transitions originate from ACTIVE, * ORIGIN → ACTIVE is the first transition, * FINAL is only entered through destruction or policy-driven completion, * no transitions occur after FINAL. Violations MUST be treated as security-critical events. 8.4. Replay of Transitions Replay attacks occur when an adversary reuses a previously valid transition record to produce unauthorized child objects. To mitigate replay: * InstanceID MUST be unique among siblings, * Lineage MUST extend deterministically, * Timestamp MUST reflect the actual transition moment, * canonical representation MUST match the transition class. Verifiers MUST reject transitions whose identity-related values indicate reuse or duplication of prior transition metadata. 8.5. Unauthorized Derivation or Transformation An adversary may attempt to produce unauthorized derived or transformed objects by forging transition metadata or manipulating canonical representation. Implementations MUST ensure that: * derivation produces a non-identical canonical representation, * transformation preserves semantic content, * materialization produces a materially distinct representation, * duplication produces a bitwise-identical representation. Any mismatch between transition class semantics and canonical representation MUST be treated as a security violation. 8.6. Destruction Misuse Destruction transitions move objects into the FINAL state. An adversary may attempt to prematurely destroy objects or conceal unauthorized transitions by forcing objects into FINAL. Verifiers MUST ensure that: * destruction preserves DigitalID, InstanceID, and Lineage, * destruction assigns a final Timestamp, * destruction is not used to bypass validation or provenance checks. Objects in FINAL MUST NOT undergo further transitions. 8.7. Interoperability with External Systems External systems such as SCITT and EMILIA rely on deterministic lifecycle behavior for provenance verification. To ensure secure interoperability: * lifecycle transitions MUST be included in signed preimages, * transition metadata MUST be referenced in transparency receipts, * verifiers MUST validate lifecycle semantics before accepting objects. Failure to enforce lifecycle validation may result in provenance confusion, unauthorized object admission, or loss of transition integrity. 8.8. Denial-of-Service Considerations Malformed or adversarial transition metadata may be used to trigger excessive validation work. Implementations SHOULD: * apply strict structural validation, * reject malformed transitions early, * limit recursion depth for lineage validation, * avoid expensive normalization or repair operations. Lifecycle validation MUST remain deterministic and bounded in complexity. 8.9. Privacy Considerations Lifecycle metadata may contain timestamps or lineage structures that reveal usage patterns or object history. Implementations SHOULD: * protect lifecycle metadata during transmission, * avoid exposing lineage unnecessarily, * apply access controls when storing transition records. Privacy-sensitive deployments MAY use pseudonymous identifiers provided canonical formatting is preserved. 9. IANA Considerations This document has no IANA actions. The lifecycle model defined in this specification does not introduce new registries, modify existing registries, or require the allocation of protocol parameters, media types, or code points. IANA is therefore requested to take no action on this document. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [SDLP-Identity] Norton, M., "SDLP RFC 1: DigitalID Specification", draft-norton-sdlp-identity-02, Work in Progress. [SDLP-ObjectFormat] Norton, M., "SDLP RFC 3: Object Format Specification", draft-norton-sdlp-object-format-02, Work in Progress. [SDLP-Lineage] Norton, M., "SDLP RFC 4: Lineage Specification", draft-norton-sdlp-lineage-01, Work in Progress. [SDLP-Security] Norton, M., "SDLP RFC 5: Security Architecture", draft-norton-sdlp-security-01, Work in Progress. [ISO8601] International Organization for Standardization, "ISO 8601:2004 — Data elements and interchange formats — Information interchange — Representation of dates and times", 2004. 11. Informative References [SCITT-Architecture] Steele, O., et al., "SCITT Architecture", draft-ietf-scitt-architecture-13, Work in Progress. [SCITT-Receipts] Steele, O., et al., "SCITT Transparency Receipts", draft-ietf-scitt-receipts-12, Work in Progress. [EMILIA] Schrock, I., "EMILIA Protocol Overview", emiliaprotocol.ai, 2026. [C2PA] Coalition for Content Provenance and Authenticity, "C2PA Specification", Version 1.3, 2024. [W3C-DID] Sporny, M., et al., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, 2022. [UUID] Leach, P., et al., "UUIDs and GUIDs", RFC 4122, DOI 10.17487/RFC4122, July 2005. Appendix A. Canonical Lifecycle Example (Informative) This appendix provides a non-normative, illustrative example of how SDLP lifecycle transitions operate in practice. The example shows how DigitalID, InstanceID, Lineage, Timestamp, and state changes interact as an object moves through the canonical lifecycle model defined in this document. A.1. Origin Object A customer acquires a digital movie titled "ExampleMovie" from a distributor. At the moment of acquisition, the distributor assigns the following DigitalID: DistributorID = dist123 CustomerID = cust456 ProductID = prod789 ProductName = ExampleMovie DownloadID = dl001 Date = 2026-07-27 Time = 14:32:10 The origin object receives: InstanceID = 1 Lineage = 1 Timestamp = 2026-07-27T14:32:10 The object enters the ORIGIN state and immediately transitions to ACTIVE. A.2. Duplication Transition (COPY) The ACTIVE origin object is duplicated to produce a bitwise-identical child object. Child identity values: DigitalID = dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 InstanceID = 1.1 Lineage = 1.1 Timestamp = 2026-07-27T14:35:02 The child enters the COPIED state and then immediately enters ACTIVE. A.3. Derivation Transition (DERIVE) The ACTIVE origin object is used to produce a derived object (e.g., a trailer, preview, or edited version). Child identity values: DigitalID = dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 InstanceID = 1.2 Lineage = 1.2 Timestamp = 2026-07-27T14:36:44 The child enters the DERIVED state and then immediately enters ACTIVE. A.4. Transformation Transition (TRANSFORM) The ACTIVE origin object is transformed (e.g., re-encoded from MP4 to MKV) while preserving semantic content. Child identity values: DigitalID = dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 InstanceID = 1.3 Lineage = 1.3 Timestamp = 2026-07-27T14:37:55 The child enters the TRANSFORMED state and then immediately enters ACTIVE. A.5. Materialization Transition (MATERIALIZE) The ACTIVE origin object is materialized into a physical or alternate modality (e.g., a rendered frame sequence or packaged DVD image). Child identity values: DigitalID = dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 InstanceID = 1.4 Lineage = 1.4 Timestamp = 2026-07-27T14:39:12 The child enters the MATERIALIZED state. Depending on implementation policy, it may enter ACTIVE or FINAL. In this example, it enters ACTIVE. A.6. Destruction Transition (FINAL) The ACTIVE origin object is retired or deleted according to system policy. Final identity values: DigitalID = dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 InstanceID = 1 Lineage = 1 Timestamp = 2026-07-27T14:40:30 The object enters the FINAL state. No further transitions are permitted. A.7. Summary The complete lifecycle sequence for the origin object is: ORIGIN → ACTIVE ACTIVE → COPIED → ACTIVE ACTIVE → DERIVED → ACTIVE ACTIVE → TRANSFORMED → ACTIVE ACTIVE → MATERIALIZED → ACTIVE ACTIVE → FINAL This example demonstrates the deterministic identity inheritance, lineage extension, timestamp assignment, and state transitions required by the SDLP lifecycle model. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com