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