SDLP RFC 2: Lifecycle State Machine
draft-norton-sdlp-lifecycle-00

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: November 2026                                          May 2026

                 SDLP RFC 2: Lifecycle State Machine
                   draft-norton-sdlp-lifecycle-00

M. Norton
Individual Submission
May 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 state machine for the Secured
   Digital Lifecycle Protocol (SDLP). The SDLP lifecycle governs the
   existence, transitions, and permitted operations of all SDLP objects.
   Each object MUST exist in exactly one lifecycle state at any given
   time, and all transitions MUST follow the deterministic rules defined
   in this document. The lifecycle state machine ensures predictable
   behavior, prevents invalid transitions, and provides a universal
   framework for object governance across SDLP implementations.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF). It represents the consensus of the IETF community. It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG). Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at the RFC Editor
   website.

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.


1.  Introduction

   The SDLP lifecycle defines the complete set of states through which a
   digital object may progress. Every SDLP object MUST exist in exactly
   one lifecycle state at any given time. All transitions MUST be
   deterministic, authorized, and recorded.

   This document defines:

   *  the SDLP lifecycle states
   *  the allowed transitions between states
   *  the rules governing state entry and exit
   *  the invariants that MUST hold within each state
   *  the security properties associated with lifecycle transitions

   The lifecycle state machine is a core component of SDLP and is
   referenced by all other SDLP specifications.

2.  Lifecycle Overview

   SDLP defines seven lifecycle states:

   1.  Creation
   2.  Activation
   3.  Distribution
   4.  Transformation
   5.  Verification
   6.  Retention
   7.  Retirement

   Each state represents a distinct phase of existence. Transitions
   between states MUST follow the rules defined in this document.

3.  State Definitions

3.1  Creation

   The Creation state represents the initial formation of an SDLP
   object. During this state:

   *  The DigitalID is assigned.
   *  The initial lineage is established.
   *  The canonical bitdump is generated.
   *  The seal is applied.

   An object MUST transition out of Creation into Activation.


3.2  Activation

   Activation represents the moment an SDLP object becomes usable. In
   this state:

   *  The object is bound to a CustomerID.
   *  The object becomes eligible for distribution.
   *  The object becomes eligible for transformation.

   Valid transitions from Activation:

   *  Activation ? Distribution
   *  Activation ? Transformation
   *  Activation ? Retention

3.3  Distribution

   Distribution represents the controlled dissemination of an SDLP
   object. In this state:

   *  The object may be delivered to authorized recipients.
   *  The object may be duplicated, producing descendant identities.
   *  The object may be exported or transferred.

   Valid transitions from Distribution:

   *  Distribution ? Transformation
   *  Distribution ? Verification
   *  Distribution ? Retention

3.4  Transformation

   Transformation represents any modification, conversion, or derivative
   operation performed on an SDLP object. In this state:

   *  A descendant DigitalID MUST be generated.
   *  Lineage MUST be extended.
   *  A new canonical bitdump MUST be produced.
   *  A new seal MUST be applied.

   Valid transitions from Transformation:

   *  Transformation ? Verification
   *  Transformation ? Retention

3.5  Verification

   Verification represents the validation of an object's integrity,
   lineage, and seal. In this state:

   *  The seal MUST be validated.
   *  The lineage MUST be validated.
   *  The DigitalID MUST be validated.

   Valid transitions from Verification:


   *  Verification ? Distribution
   *  Verification ? Retention
   *  Verification ? Retirement (if validation fails)

3.6  Retention

   Retention represents long-term storage or archival. In this state:

   *  The object is stable and inactive.
   *  No transformations may occur.
   *  The object may be reactivated or retired.

   Valid transitions from Retention:

   *  Retention ? Distribution
   *  Retention ? Verification
   *  Retention ? Retirement

3.7  Retirement

   Retirement represents the terminal state of an SDLP object. In this
   state:

   *  The object is no longer active.
   *  The object MUST NOT be transformed.
   *  The object MUST NOT be distributed.
   *  The object MUST NOT re-enter any previous state.

   Retirement is irreversible.

4.  State Machine Rules

4.1  Determinism

   All lifecycle transitions MUST be deterministic. No implementation
   may introduce nondeterministic or probabilistic transitions.

4.2  Exclusivity

   An SDLP object MUST exist in exactly one lifecycle state at any given
   time.

4.3  Valid Transitions

   Implementations MUST enforce the valid transitions defined in this
   document. Any attempt to perform an invalid transition MUST be
   rejected.

4.4  Transition Logging

   All transitions MUST be recorded in the object's lifecycle log,
   including:


   *  previous state
   *  next state
   *  timestamp
   *  actor
   *  justification

5.  Security Properties

   Lifecycle transitions MUST preserve:

   *  DigitalID integrity
   *  lineage integrity
   *  seal validity
   *  state invariants

   Unauthorized transitions MUST be rejected.

6.  Integrity and Tamper Resistance

   Lifecycle transitions MUST NOT modify:

   *  the root DigitalID
   *  historical lineage entries
   *  previous lifecycle logs

   Any attempt to alter lifecycle history MUST be treated as tampering
   and MUST cause verification failure.

7.  IANA Considerations

   This document makes no requests of IANA.

8.  Security Considerations

   Unauthorized transitions, forged lineage, or invalid seals MUST be
   treated as security violations. Implementations MUST ensure that all
   transitions are authenticated and authorized.

9.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", RFC 8174, May 2017.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", RFC 2026, October 1996.

Author's Address

M. Norton
   El Mirage, Arizona
   United States
   Email: mark433norton@gmail.com