SDLP RFC 2: Lifecycle Specification
draft-norton-sdlp-lifecycle-01

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