Internet-Draft M. Norton Intended status: Informational Independent Expires: January 2, 2027 July 2, 2026 SDLP RFC 2: Lifecycle Specification draft-norton-sdlp-lifecycle-01 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. 1. Introduction The SDLP Lifecycle Model defines the canonical state machine used by all SDLP-governed objects. Every object managed under SDLP passes through a predictable sequence of states, each representing a distinct phase of existence. The lifecycle model provides a stable framework for describing how objects are created, duplicated, transformed, transmitted, and materialized across SDLP-compliant systems. The lifecycle model is independent of identity, lineage, and security semantics. Identity is defined in draft-norton-sdlp- identity-01. Security properties and enforcement behaviors are defined in draft-norton-sdlp-sec-arch-02. Lineage grammar and ancestry rules are defined in draft-norton-sdlp-lineage-01. The lifecycle model interacts with these specifications but does not redefine or override them. The purpose of the lifecycle model is to provide a consistent and interoperable description of object evolution. Implementations rely on lifecycle semantics to determine when identity must be assigned, when lineage must be extended, and when security posture must be evaluated. Lifecycle rules ensure that SDLP objects behave predictably across all compliant systems and transports. This document updates and formalizes the lifecycle semantics originally introduced in draft-norton-sdlp-lifecycle-00. 2. Lifecycle Overview The SDLP Lifecycle Model defines a canonical state machine that describes how SDLP-governed objects evolve over time. Each object transitions through a sequence of well-defined states, and each transition corresponds to a specific type of lifecycle event. The lifecycle model ensures that all SDLP implementations interpret object evolution consistently and apply identity, lineage, and security rules at the correct points in the object's lifetime. The lifecycle model is intentionally simple. It does not define physics, destruction semantics, or cryptographic sealing behavior. Those functions are defined in companion SDLP specifications. The lifecycle model focuses exclusively on describing the structural evolution of objects and the events that cause state transitions. Every SDLP object begins in an initial creation state, transitions through one or more evolution states, and may eventually reach a terminal state. Implementations MUST follow the lifecycle model exactly as defined in this document. Deviations from the canonical state machine may result in incorrect identity assignment, invalid lineage extension, or improper security posture evaluation. The following sections define the lifecycle states, the events that trigger transitions between states, and the rules governing how implementations MUST process those transitions. 3. Lifecycle States The SDLP Lifecycle Model defines a canonical set of states through which all SDLP-governed objects MUST progress. Each state represents a distinct phase of object existence, and each transition between states corresponds to a specific lifecycle event. Implementations MUST interpret and apply these states consistently to ensure interoperability across SDLP-compliant systems. The lifecycle states defined in this section describe structural evolution only. They do not define destruction semantics, sealing behavior, or any form of SDLP physics. Those functions are specified in companion SDLP documents. The lifecycle states focus exclusively on how objects are created, duplicated, transformed, transmitted, and materialized. The canonical lifecycle states are: * Created: the initial state assigned when an object first comes into existence. Identity assignment occurs in this state. * Duplicated: the state entered when an object is copied or replicated. Lineage MUST be extended during this transition. * Transformed: the state entered when an object undergoes a structural or representational change. Identity is preserved and lineage MUST be extended. * Transmitted: the state representing movement of an object across systems, transports, or boundaries. Identity and lineage remain stable. * Materialized: the state entered when an object becomes available for use, inspection, or processing within a receiving system. * Terminal: the final state indicating that no further lifecycle transitions will occur. Identity and lineage remain valid and MUST NOT be altered. These states form the foundation of the SDLP lifecycle model. The following sections define the events that trigger transitions between these states and the rules governing how implementations MUST process those transitions. 4. Lifecycle Events Lifecycle events define the conditions under which an SDLP-governed object transitions from one lifecycle state to another. Each event corresponds to a specific type of structural evolution and MUST be processed according to the rules defined in this section. Lifecycle events do not define destruction semantics, sealing behavior, or any form of SDLP physics. Those functions are specified in companion SDLP documents. Lifecycle events are classified into four categories: creation events, duplication events, transformation events, and transmission events. Each category corresponds to a distinct type of object evolution and results in a transition to one of the canonical lifecycle states defined in Section 3. 4.1 Creation Event A creation event occurs when an object first comes into existence. The Identity Authority assigns the initial DigitalID, sets lineage to "1", and records the creation timestamp. The object enters the Created state. Creation events MUST NOT reuse identity components from any existing object. 4.2 Duplication Event A duplication event occurs when an object is copied or replicated. The object enters the Duplicated state. Implementations MUST extend the lineage component by appending a new positive integer. All other identity components MUST remain unchanged. Duplication events MUST NOT overwrite or replace existing objects. 4.3 Transformation Event A transformation event occurs when an object undergoes a structural or representational change. The object enters the Transformed state. Identity MUST be preserved and lineage MUST be extended. A transformation event does not alter DistributorID, CustomerID, ProductID, ProductName, or DownloadID. 4.4 Transmission Event A transmission event occurs when an object moves across systems, transports, or boundaries. The object enters the Transmitted state. Identity and lineage remain stable and MUST NOT be altered. A transmission event does not create a descendant identity. 4.5 Materialization Event A materialization event occurs when an object becomes available for use, inspection, or processing within a receiving system. The object enters the Materialized state. Materialization does not modify identity or lineage. 4.6 Terminal Event A terminal event occurs when an object reaches a final state in which no further lifecycle transitions will occur. The object enters the Terminal state. Identity and lineage remain valid and MUST NOT be altered. Terminal events do not define destruction semantics. 5. Lifecycle Transition Rules Lifecycle transitions define how SDLP-governed objects move from one lifecycle state to another. Each transition is triggered by a specific lifecycle event and MUST follow the rules defined in this section. Implementations MUST apply these rules consistently to ensure interoperability across SDLP-compliant systems. Lifecycle transitions do not define destruction semantics, sealing behavior, or any form of SDLP physics. Those functions are specified in companion SDLP documents. Transition rules focus exclusively on structural evolution and the correct application of identity and lineage semantics. 5.1 Creation Transition A creation event transitions an object into the Created state. The Identity Authority assigns the initial DigitalID, sets lineage to "1", and records the creation timestamp. Creation transitions MUST NOT reuse identity components from any existing object. 5.2 Duplication Transition A duplication event transitions an object into the Duplicated state. Implementations MUST extend the lineage component by appending a new positive integer. All other identity components MUST remain unchanged. Duplication transitions MUST NOT overwrite or replace existing objects. 5.3 Transformation Transition A transformation event transitions an object into the Transformed state. Identity MUST be preserved and lineage MUST be extended. A transformation transition MUST NOT alter DistributorID, CustomerID, ProductID, ProductName, or DownloadID. 5.4 Transmission Transition A transmission event transitions an object into the Transmitted state. Identity and lineage remain stable and MUST NOT be altered. Transmission transitions do not create descendant identities. 5.5 Materialization Transition A materialization event transitions an object into the Materialized state. Materialization does not modify identity or lineage. The object becomes available for use, inspection, or processing within a receiving system. 5.6 Terminal Transition A terminal event transitions an object into the Terminal state. No further lifecycle transitions will occur. Identity and lineage remain valid and MUST NOT be altered. Terminal transitions do not define destruction semantics. 6. Identity and Lineage Requirements During Lifecycle Transitions Identity and lineage are foundational properties of SDLP-governed objects. Lifecycle transitions MUST preserve these properties exactly as defined in draft-norton-sdlp-identity-01 and draft- norton-sdlp-lineage-01. Implementations MUST apply identity and lineage rules consistently during every lifecycle event to ensure interoperability across SDLP-compliant systems. Identity assignment occurs only during creation. All other lifecycle transitions preserve the existing identity and extend lineage when required. No lifecycle transition may rewrite, replace, or alter any identity component except lineage and timestamp. 6.1 Identity Preservation All lifecycle transitions except creation MUST preserve the full DigitalID assigned to the object. DistributorID, CustomerID, ProductID, ProductName, and DownloadID MUST remain unchanged across all transitions. Implementations MUST treat the DigitalID as an immutable identifier and MUST NOT regenerate or modify identity components during duplication, transformation, transmission, or materialization. 6.2 Lineage Extension Lineage MUST be extended during duplication and transformation transitions. Implementations MUST append a new positive integer to the lineage component according to the canonical lineage grammar. Lineage MUST NOT be reused, reordered, truncated, or replaced. Transmission and materialization transitions do not extend lineage. 6.3 Timestamp Requirements Each lifecycle transition MUST record a timestamp that reflects the actual time of the event. Timestamps MUST follow the canonical SDLP timestamp format. Creation, duplication, transformation, and materialization transitions MUST record a new timestamp. Transmission transitions MAY record a timestamp but MUST NOT modify identity or lineage. 6.4 Descendant Identity Requirements Descendant identities created during duplication or transformation transitions MUST preserve all identity components except lineage and timestamp. Descendants MUST NOT alter DistributorID, CustomerID, ProductID, ProductName, or DownloadID. Descendants MUST extend lineage exactly once per transition. 6.5 Rejection Requirements Implementations MUST reject any lifecycle transition that attempts to modify identity components other than lineage and timestamp. Transitions that produce invalid lineage, malformed timestamps, or non-canonical DigitalIDs MUST be treated as errors. Invalid transitions MUST NOT be repaired or partially accepted. A correct descendant identity MUST be generated instead. 7. Validation Rules for Lifecycle Processing Implementations MUST validate every lifecycle transition before accepting, storing, or processing it. Validation ensures that the transition conforms to the lifecycle states, events, identity requirements, and lineage rules defined in this specification and in companion SDLP documents. Invalid transitions MUST be rejected. 7.1 State Validation Implementations MUST verify that the object is currently in a valid lifecycle state before applying a transition. Transitions that do not correspond to the object's current state MUST be rejected. Objects MUST NOT skip states, regress to previous states, or enter states not defined in Section 3. 7.2 Event Validation Implementations MUST verify that the lifecycle event triggering the transition is well-formed and corresponds to one of the canonical event types defined in Section 4. Events that do not match a recognized type MUST be rejected. Events MUST NOT redefine or override identity, lineage, or security semantics. 7.3 Identity Validation Implementations MUST verify that identity components are preserved exactly as defined in draft-norton-sdlp-identity-01. DistributorID, CustomerID, ProductID, ProductName, and DownloadID MUST remain unchanged across all transitions except creation. Transitions that attempt to modify these components MUST be rejected. 7.4 Lineage Validation Implementations MUST verify that lineage is extended only when required and only according to the canonical lineage grammar defined in draft-norton-sdlp-lineage-01. Lineage MUST be extended during duplication and transformation transitions and MUST remain unchanged during transmission and materialization transitions. Invalid lineage values MUST cause the transition to be rejected. 7.5 Timestamp Validation Implementations MUST verify that the timestamp associated with the transition is well-formed, comparable, and consistent with the canonical SDLP timestamp format. Transitions with malformed or inconsistent timestamps MUST be rejected. 7.6 Structural Validation Implementations MUST verify that the transition does not introduce additional states, remove required states, or alter the canonical lifecycle model. Transitions that attempt to bypass, reorder, or redefine lifecycle states MUST be rejected. 7.7 Rejection Requirements If any validation step fails, the lifecycle transition MUST be rejected. No implementation MAY accept a transition that violates state rules, event rules, identity requirements, lineage grammar, timestamp format, or structural constraints. Rejected transitions MUST NOT be repaired or partially accepted. A correct transition MUST be generated instead. 8. Security Considerations The SDLP Lifecycle Model does not define security enforcement, cryptographic behavior, destruction semantics, or any form of SDLP physics. Those functions are specified in draft-norton-sdlp-sec- arch-02. The lifecycle model focuses exclusively on structural evolution and the rules governing how SDLP objects transition between states. Although lifecycle transitions do not perform security operations, they interact with security semantics in several important ways. Implementations MUST ensure that identity and lineage remain stable and tamper-evident across all lifecycle transitions. Unauthorized modification of identity or lineage during a transition constitutes a security violation and MUST be detectable through canonical validation rules. Lifecycle transitions that occur across system boundaries may expose objects to environments with different security postures. Implementa- tions MUST ensure that transmission and materialization transitions preserve identity and lineage exactly and do not introduce ambiguity or opportunities for impersonation, collision, or unauthorized rewriting. Implementations MUST reject lifecycle transitions that produce malformed identity components, invalid lineage values, or non- canonical DigitalIDs. Accepting such transitions may enable identity spoofing, lineage falsification, or other forms of structural attack. The lifecycle model assumes that all security enforcement, including authentication, authorization, sealing, and destruction behavior, is performed by SDLP-compliant systems according to draft-norton-sdlp- sec-arch-02. Lifecycle transitions MUST NOT bypass or override security requirements defined in the SDLP security architecture. 9. IANA Considerations This document has no IANA actions. It does not define new protocol parameters, create new registries, or modify existing registries. No IANA review is required. 10. Normative References [SDLP-IDENTITY] Norton, M., "SDLP RFC 1: Identity Specification", draft-norton-sdlp-identity-01, July 2026. [SDLP-LINEAGE] Norton, M., "SDLP RFC 3: Lineage Specification", draft-norton-sdlp-lineage-01, July 2026. [SDLP-SECARCH] Norton, M., "SDLP RFC 4: Security Architecture", draft-norton-sdlp-sec-arch-02, July 2026. [ISO8601] International Organization for Standardization, "ISO 8601:2004 - Data elements and interchange formats - Information interchange - Representation of dates and times", December 2004. 11. Informative References [SDLP-LIFECYCLE-00] Norton, M., "SDLP RFC 2: Lifecycle Specification", draft-norton-sdlp-lifecycle-00, May 2026. [SDLP-OVERVIEW] Norton, M., "SDLP Overview and Architectural Summary", draft-norton-sdlp-overview-00, work in progress. [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. 12. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com