SDLP Architecture (arch)
draft-norton-sdlp-arch-02

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: December 26, 2026                                 June 24, 2026

                        SDLP Architecture (arch)
                      draft-norton-sdlp-arch-02

M. Norton
Email: mark433norton@gmail.com
June 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

   The Secured Digital Lifecycle Protocol (SDLP) defines an architecture
   for lifecycle-governed digital objects. SDLP introduces a uniform
   model for object identity, provenance, state transitions, and
   authorized transformations, enabling digital goods to enforce their
   own lifecycle rules across heterogeneous systems and distribution
   environments.

   This document describes the architectural components that support
   SDLP objects, including identity construction, lifecycle state
   definitions, transition conditions, and the mechanisms by which
   objects validate their own integrity and permitted operations. The
   architecture defines how SDLP objects are created, transformed,
   distributed, consumed, and retired, and specifies the interoperability
   requirements needed for consistent behavior across independent
   implementations.

   This document does not define wire formats or protocol exchanges.
   Instead, it provides the architectural foundation upon which SDLP
   protocol specifications, security mechanisms, and implementation
   profiles can be built.

Status of This Memo

   This Internet-Draft is being made available through the Independent
   Submission Stream. It is not a product of the Internet Engineering
   Task Force (IETF) and does not represent IETF consensus or IESG
   approval. It is published for informational purposes.

   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."

   Information about the current status of this document, any errata,
   and how to provide feedback 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.

Table of Contents

   0.  Architectural Purpose
   1.  Introduction
   2.  Purpose of SDLP
   3.  Design Principles
   4.  Terminology
   5.  Lifecycle Model Overview
   6.  Out-of-Scope Items
   7.  Security Considerations
   8.  IANA Considerations

   9.  System Model
   10. Architectural Overview
   11. Threat Model
   12. Interoperability Considerations
   13. Deployment Considerations
   14. Example Lifecycle
   15. Instance Uniqueness and Anti-Cloning Guarantees
   16. Infertile Instances (Software and Games)
   17. Decay Model and Vitality Transfer

   18. Forensic Model and Unnatural Death
   19. Absence of Physical Export Transitions
   20. Autonomous Enforcement Through Lifecycle Physics
   21. Platform-Agnostic and Forward-Compatible Architecture
   22. Security Considerations (Final)
   23. References
       23.1 Normative References
       23.2 Informative References
   24. Acknowledgments
   25. Author's Address

   Appendix A.  Rationale for Architecture-02


0.  Architectural Purpose

   The Secured Digital Lifecycle Protocol (SDLP) defines a deterministic
   lifecycle model for digital objects. The architecture assumes that
   user behavior, operational environments, and administrative controls
   cannot be relied upon to provide consistent security guarantees.
   Consequently, SDLP does not depend on user intent, discretionary
   policy enforcement, or external trust assumptions.

   SDLP establishes mandatory lifecycle rules that govern the creation,
   existence, transition, and termination of digital instances. These
   rules are enforced by the instances themselves and are not subject to
   override by users or intermediaries.

   The architecture supports a security model in which digital objects
   validate their own state, detect unauthorized conditions, and enter
   terminal destruction states when required. This approach ensures that
   object integrity and lifecycle compliance are maintained even in the
   presence of operational error, misconfiguration, or malicious
   activity.

   The purpose of SDLP is to provide lifecycle integrity in environments
   where external behavioral or administrative controls cannot be
   guaranteed.

1.  Introduction

   SDLP defines a deterministic lifecycle for digital goods that
   restricts unauthorized duplication and distribution. It enforces
   immutable identity, continuous lineage, controlled activation, and
   irreversible termination to ensure objects cannot be misused or
   replicated outside authorized environments.

2.  Purpose of SDLP

   SDLP provides a secured, deterministic lifecycle for digital goods to
   ensure that protected content remains controlled, that purchase events
   remain trusted, and that objects cannot be extracted, cloned,
   tampered with, or instantiated outside authorized environments. It
   achieves this through immutable identity, continuous lineage,
   mandatory policy binding, environment-trust evaluation, tamper
   reactivity, Initialization as a trust boundary, and irreversible
   destruction semantics.

3.  Design Principles

   SDLP is governed by the following core principles:

   *  P1. Identity First - Every digital object MUST possess a persistent
      DigitalID that uniquely identifies it across its entire existence.

   *  P2. Lifecycle Determinism - Every object MUST exist in exactly one
      lifecycle state at any given time, and all transitions MUST be
      deterministic and protocol-defined.

   *  P3. Transformation Integrity - All transformations MUST be
      explicit, authenticated, and lineage-preserving.


   *  P4. Environment Trust - An object MUST NOT activate in an
      environment that cannot uphold SDLP's security guarantees.

   *  P5. Tamper Reactivity - Objects MUST detect and respond to tamper,
      replay, debugging, or instrumentation attempts.

   *  P6. Destruction Finality - Zeroization-class terminal states MUST
      be irreversible, and destroyed objects MUST NOT be recoverable,
      rehydrated, resurrected, or reinstantiated.

   *  P7. Initialization as a Trust Boundary - Initialization MUST serve
      as the mandatory evaluation point at which an object determines
      whether activation is safe. Failure of any precondition MUST
      result in Pre-Init Termination.

4.  Terminology

   DigitalID: The persistent identity of a digital object.

   Instance: A specific materialization of a DigitalID.

   Lineage Seed: The initial lineage context from which all lineage is
      derived.

   ObjectKey: Cryptographic key material bound to an instance.

   Lifecycle State: A protocol-defined phase of existence.

   Initialization: The trust boundary at which an instance evaluates its
      environment before activation.

   Pre-Init Termination: Termination prior to activation due to unmet
      Initialization requirements.

   Zeroization: Irreversible destruction of an instance, after which no
      recovery or reinstantiation is possible.

   Transformation: A rule-governed change to an object or instance.

   Retirement: The terminal lifecycle state for objects that complete
      their lifecycle without tamper or destruction.

5.  Lifecycle Model Overview

   SDLP defines a universal lifecycle model consisting of five phases:

   1.  Embryo - The encoded, inert form of an instance prior to
       Initialization.

   2.  Initialization - The trust boundary at which the instance
       evaluates its environment; failure results in Pre-Init
       Termination.

   3.  Activation - The point at which the instance becomes active.

   4.  Lifecycle Operation - The phase in which the instance may be
       distributed, transformed, verified, or retained.


   5.  Termination - The irreversible conclusion of the lifecycle,
       typically through Zeroization or Retirement.

   SDLP Identity defines the DigitalID. SDLP Lifecycle defines the state
   machine. SDLP Transformation defines transformation rules and lineage
   guarantees.

6.  Out-of-Scope Items

   The following items are out of scope for this document. SDLP defines
   lifecycle rules, not the implementation details of systems that adopt
   them.

   *  Implementation details
   *  Transport mechanisms
   *  Storage formats
   *  Cryptographic algorithm selection
   *  Commercial licensing models
   *  UI or UX considerations
   *  External content-protection mechanisms (e.g., DRM)

7.  Security Considerations

   SDLP requires that all lifecycle transitions be authenticated,
   authorized, and recorded. Identity spoofing, unauthorized
   transformations, lineage tampering, and state forgery MUST be
   mitigated by protocol-level controls defined in the SDLP Security
   Architecture.

   Initialization is a mandatory trust boundary. Instances MUST evaluate
   their environment prior to activation and MUST perform Pre-Init
   Termination if any requirement is unmet.

   Zeroization-class terminal states MUST be irreversible, and destroyed
   instances MUST NOT be recoverable, rehydrated, resurrected, or
   reinstantiated.

   These requirements ensure that SDLP instances uphold lifecycle
   guarantees regardless of user behavior or platform integrity.

8.  IANA Considerations

   This document makes no requests of IANA.

Appendix A.  Rationale for Architecture-02

   Architecture-02 refines the foundation introduced in Architecture-01
   by clarifying terminology, removing non-essential narrative elements,
   and aligning the document with the tone expected of an architectural
   specification. Its purpose is to provide a clearer description of
   SDLP identity, lineage, lifecycle states, and transitions so that
   subsequent SDLP documents share a consistent framework.

9.  System Model

   SDLP operates within an ecosystem consisting of four primary actors:


   *  Producers: Entities that create digital goods and assign the
      initial DigitalID and lineage seed.

   *  Distributors: Entities that deliver instances while preserving
      lineage, enforcing lifecycle constraints, and upholding
      Initialization requirements.

   *  Customers: End users who receive, activate, transform, and retain
      digital goods in accordance with SDLP rules and environmental
      trust conditions.

   *  Verifiers: Independent entities that validate identity, lineage,
      lifecycle state, and termination status without accessing
      protected content.

   SDLP defines the interactions among these actors, their boundaries of
   responsibility, and the lifecycle transitions that govern the
   movement and behavior of digital goods.

10.  Architectural Overview

   SDLP architecture is organized around three foundational constructs:

   *  DigitalID: A persistent, globally unique identifier anchoring all
      lifecycle behavior.

   *  Instance Record: A lineage-preserving record of each
      materialization of a DigitalID, including creation, distribution,
      transformation, and termination events.

   *  Lifecycle State Machine: A deterministic model defining allowable
      transitions, including Initialization, active states, and
      Zeroization-class terminal states.

   These constructs are decoupled from transport, cryptographic
   algorithms, and storage formats to support heterogeneous
   implementations. SDLP emphasizes verifiability, minimal disclosure,
   and deterministic behavior. All transitions MUST be authenticated,
   authorized, and recorded in a lineage-preserving manner.

11.  Threat Model

   SDLP is designed to mitigate the following threats:

   *  Identity Spoofing: Unauthorized creation or modification of a
      DigitalID.

   *  Lineage Tampering: Alteration of instance history to conceal
      unauthorized duplication or transformation.

   *  Unauthorized Transformation: Modification of a digital object
      without proper authentication or lifecycle compliance.

   *  State Forgery: Misrepresentation of lifecycle state to bypass
      restrictions or gain unauthorized access.


   *  Environment Compromise: Activation attempts in corrupted,
      tampered, replayed, debugged, or untrusted environments.

   *  Resurrection and Reinstantiation: Attempts to revive destroyed
      instances or reuse identity, lineage, or key material.

   SDLP does not define content-access controls; such mechanisms may be
   provided by higher-layer systems. SDLP ensures that digital objects
   cannot exist, activate, or persist outside environments capable of
   enforcing SDLP lifecycle guarantees.

12.  Interoperability Considerations

   SDLP is designed to operate across cloud services, local devices, and
   offline environments. To ensure interoperability:

   *  DigitalID formats MUST be stable and globally unique.
   *  Lifecycle transitions MUST be deterministic and verifiable.
   *  Transformation records MUST preserve lineage across systems.
   *  Implementations SHOULD support offline validation.

   SDLP does not mandate a serialization format; implementers may use
   JSON, CBOR, XML, or other encodings. SDLP defines lifecycle rules,
   not implementation details.

13.  Deployment Considerations

   Deployments of SDLP SHOULD consider:

   *  Storage durability for lineage and instance records.
   *  Secure key management for transition authentication.
   *  Revocation or retirement mechanisms for compromised instances.
   *  Scalability of verification services.
   *  Enforcement of Initialization prerequisites across platforms and
      trust domains.

   SDLP is agnostic to infrastructure choices and supports centralized,
   federated, and decentralized deployments. Deployments MUST uphold
   SDLP lifecycle guarantees regardless of platform architecture.

14.  Example Lifecycle

   The following example illustrates a typical SDLP lifecycle:

   1.  A producer creates a digital good and assigns DigitalID "D123".
   2.  A distributor generates Instance "I1" and delivers it to a
       customer.
   3.  The customer activates the instance after successful
       Initialization.
   4.  The customer performs a permitted transformation, generating
       Instance "I2" with preserved lineage.
   5.  The customer retires the instance, transitioning it to the
       Retired state.

   All transitions are authenticated, authorized, and recorded in
   accordance with SDLP lifecycle rules.


15.  Instance Uniqueness and Anti-Cloning Guarantees

   SDLP defines digital goods as lineage-bearing instances rather than
   infinitely replicable files. Each instance is assigned a globally
   unique Instance Identifier (IID). No two instances may share an IID,
   and no operation may produce a duplicate or parallel instance.

   Any operation that produces a new instance is a reproduction event.
   The parent loses half of its remaining vitality, and the child
   receives the other half. This halving rule prevents identical or
   full-strength clones.

   Parallel copying does not exist in SDLP. Each reproduction event is
   singular and MUST result in a unique IID and a unique vitality value.
   Because vitality is divided at each reproduction, no two instances
   can possess identical state, lineage position, or remaining plays.

   Uploading is treated as reproduction and follows the same decay
   rules. Instances that can be uploaded can also be streamed, and each
   stream consumes one unit of vitality.

   SDLP allows no clones. Every instance is a distinct digital organism
   with its own identity, vitality, and lifecycle trajectory.

16.  Infertile Instances (Software and Games)

   SDLP classifies certain digital goods�such as software applications,
   interactive games, and other licensed executables�as infertile
   instances. An infertile instance has no lifecycle transitions capable
   of producing children. It cannot be copied, uploaded, exported,
   transformed, or otherwise reproduced through any SDLP-defined
   mechanism.

   Infertile instances are issued as single, non-reproductive digital
   organisms. Each installation, entitlement, or license seat is its own
   independent instance with a unique IID. These instances have no fork
   transition, no decay-based reproduction, and no lineage. Their
   lifecycle consists of creation, Initialization, activation, permitted
   use, and retirement.

   Because infertile instances cannot reproduce, they do not participate
   in vitality halving or lineage-bearing transitions. They maintain a
   fixed vitality model appropriate to their licensing semantics, and
   their state cannot be transferred or inherited by any other instance.

   This model reflects the operational realities of software licensing.
   SDLP formalizes these constraints by ensuring that software and games
   are inherently infertile and cannot be cloned or redistributed through
   any lifecycle transition.

17.  Decay Model and Vitality Transfer

   SDLP defines vitality as the finite, consumable resource governing the
   usable lifespan of an instance. Vitality is represented as a numeric
   value P and decreases through use and reproduction. Vitality
   determines whether an instance can perform further lifecycle
   transitions and whether its death is natural or unnatural.


   Reproduction events�including copying, uploading, and permitted
   transformations�are decay transitions. During a decay transition, the
   parent loses half of its remaining vitality, and the child receives
   the other half. This halving rule ensures that reproduction is always
   diminishing and prevents identical or full-strength clones.

   Vitality is also consumed through play events. Each play reduces P by
   one. Instances that can be uploaded may be streamed, and each stream
   counts as a play. Excessive concurrency (more than ten simultaneous
   plays) is a violation and results in premature destruction.

   Natural death occurs when vitality falls below one (P < 1), at which
   point the instance transitions to the Retired state without producing
   a forensic record.

   Unnatural death occurs when an instance is destroyed while vitality
   remains (P >= 1), such as through tamper, piracy, or unauthorized
   transitions. In these cases, the instance performs a bitdump and
   emits a forensic record as defined in Section 20.

   The decay model ensures predictable, diminishing lifecycles. Vitality
   transfer enforces scarcity, prevents cloning, and provides a
   tamper-evident history of use and reproduction.

18.  Forensic Model and Unnatural Death

   SDLP defines a unified forensic model for instances that experience
   unnatural death. Unnatural death occurs when an instance is destroyed
   while vitality remains (P >= 1), such as through tamper, piracy,
   unauthorized transitions, environment spoofing, debugger attachment,
   or lineage corruption.

   When unnatural death occurs, two artifacts are produced:

   *  Lifecycle Death Report (LDR): A structured summary of the event,
      including identity, lineage position, remaining vitality, and
      classified cause of destruction.

   *  Digital DNA: A cryptographically sealed forensic record capturing
      the instance's identity, lineage, vitality, and environmental
      context at the moment of death.

   Together, these artifacts form the complete post-mortem record of an
   unnatural death. Both are sealed at the moment of death and cannot be
   altered, suppressed, or regenerated by any SDLP transition.

   Instances that reach natural death (P < 1) retire silently and
   produce no forensic artifacts.

   The forensic model provides a tamper-evident, self-authenticating
   record of premature destruction. Operational handling and verification
   of LDRs and Digital DNA are defined in the SDLP Security Architecture.


19.  Absence of Physical Export Transitions

   SDLP instances are lifecycle-bound organisms whose permitted
   transitions are limited to those defined by the protocol. No instance
   may undergo a transition that results in physical export,
   externalization, or reconstruction of its data outside the
   SDLP-governed environment.

   Physical export operations�including file extraction, raw byte
   copying, container unpacking, disk imaging, debugger-based memory
   capture, or reconstruction as a traditional file�are not part of the
   SDLP lifecycle and are classified as illegal transitions.

   Because instances are defined by vitality, lineage, and internal
   state, any attempt to externalize or reconstitute an instance outside
   the protocol results in immediate unnatural death (P >= 1) and
   triggers the forensic process defined in Section 18.

   SDLP provides no mechanism for exporting an instance into a non-SDLP
   format. Instances cannot be converted into files, duplicated through
   external tooling, or reconstructed from memory or storage artifacts.
   The absence of physical export transitions ensures that digital goods
   remain lifecycle-bound, tamper-evident, and non-replicable outside
   the SDLP environment.

20.  Autonomous Enforcement Through Lifecycle Physics

   SDLP achieves enforcement through the intrinsic physics of its
   lifecycle model. Rules governing reproduction, vitality, lineage,
   Initialization, and death are self-enforcing and require no external
   authority or supervisory infrastructure.

   The halving rule prevents cloning by ensuring that each reproduction
   event diminishes vitality and produces a unique child instance. The
   absence of physical export transitions prevents instances from being
   reconstructed outside the SDLP environment. Illegal transitions
   result in immediate unnatural death (P >= 1) and trigger the forensic
   process defined in Section 18.

   These mechanisms ensure that instances cannot be silently tampered
   with, copied, or redistributed. Violations are inherently
   self-destructive and self-reporting, and no central validator is
   required for the protocol to function.

   Organizations may choose to receive and interpret LDRs and Digital
   DNA, but such roles are external to the SDLP architecture. They are
   consumers of the forensic truth emitted by the protocol.

   SDLP�s enforcement model is intrinsic rather than supervisory.
   Instances that violate the Secured Digital Laws of Physics simply
   cease to exist, leaving behind an immutable forensic record of their
   demise.


21.  Autonomous Enforcement Through Lifecycle Physics

   SDLP enforces itself through the intrinsic physics of its lifecycle
   model. Rules governing reproduction, vitality, lineage,
   Initialization, and death are self-enforcing and require no external
   authority or supervisory infrastructure.

   The halving rule prevents cloning by ensuring that each reproduction
   event diminishes vitality and produces a unique child instance. The
   absence of physical export transitions prevents instances from being
   reconstructed outside the SDLP environment. Illegal transitions
   result in immediate unnatural death (P >= 1) and trigger the forensic
   process defined in Section 18.

   These mechanisms ensure that instances cannot be silently tampered
   with, copied, or redistributed. Violations are inherently
   self-destructive and self-reporting, and no central validator is
   required for the protocol to function.

   Organizations may choose to receive and interpret forensic artifacts,
   but such roles are external to the SDLP architecture. They are
   consumers of the truth emitted by the protocol.

   SDLP�s enforcement model is intrinsic rather than supervisory.
   Instances that violate the Secured Digital Laws of Physics simply
   cease to exist, leaving behind an immutable forensic record.

22.  Platform-Agnostic and Forward-Compatible Architecture

   SDLP operates independently of any operating system, device class,
   marketplace, or distribution environment. An instance retains its
   identity, vitality, lineage, and lifecycle constraints regardless of
   where it is executed or consumed.

   All lifecycle rules are intrinsic to the instance. SDLP does not rely
   on platform-level enforcement, external infrastructure, or vendor-
   specific integration. The protocol behaves uniformly across
   heterogeneous environments and technological generations.

   Interoperability and longevity are provided by the instance�s internal
   lifecycle engine, which governs all transitions without external
   validation. Platforms may expose metadata, verify authenticity, or
   consume forensic artifacts, but such behavior is optional and does not
   affect protocol correctness.

   Because SDLP separates its immutable lifecycle physics from the
   replaceable components of surrounding ecosystems, instances remain
   valid and self-governing on future systems without modification. An
   instance created today will behave identically on future platforms,
   preserving its vitality, lineage, and forensic guarantees.

   This architecture ensures that SDLP-governed digital goods remain
   universal, portable, durable, and tamper-evident across evolving
   devices, marketplaces, and distribution paradigms.


23.  Security Considerations

   SDLP defines a lifecycle model in which all security guarantees are
   enforced by the instance itself. Earlier sections describe the
   protocol�s defenses against identity spoofing, lineage tampering,
   unauthorized transformation, state forgery, and activation in
   untrusted environments. This section summarizes the implications of
   those requirements.

   SDLP instances MUST authenticate all lifecycle transitions, preserve
   lineage integrity, and enforce Initialization as a mandatory trust
   boundary. Instances MUST detect tamper, replay, debugging, or
   instrumentation attempts and MUST perform unnatural death when such
   conditions are encountered.

   Zeroization-class terminal states MUST be irreversible. Destroyed
   instances MUST NOT be recoverable, rehydrated, resurrected, or
   reinstantiated. Implementations MUST ensure that key material,
   lineage records, and internal state are securely erased during
   termination.

   SDLP does not define content-access controls or platform-level
   security mechanisms. Implementations MUST ensure that surrounding
   systems do not undermine SDLP lifecycle guarantees, particularly
   during Initialization, reproduction, and termination events.

   The security of SDLP relies on correct implementation of lifecycle
   physics, deterministic transitions, and tamper reactivity. Failure to
   uphold these requirements may result in unauthorized duplication,
   lineage corruption, or premature destruction of instances.

24.  References

24.1.  Normative References

   [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.

24.2.  Informative References

   (None)

25.  Acknowledgments

   The author thanks the reviewers and contributors who provided feedback
   on earlier versions of this document. Their insights helped refine the
   terminology, clarify lifecycle semantics, and improve the overall
   structure of the SDLP architecture.

26.  Author�s Address

   M. Norton
   Email: mark433norton@gmail.com