Internet-Draft M. Norton Intended status: Informational Independent Expires: January 1, 2027 July 1, 2026 SDLP Architecture (arch) draft-norton-sdlp-arch-03 M. Norton 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 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. Terminology 3. Object Identity 4. Lifecycle Semantics 5. Lineage Model 6. Environment Validation 7. Security Considerations 8. IANA Considerations 23. References 24. Acknowledgments 25. Author’s Address Appendix A. Rationale 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. 0.1. 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) 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines identity, lineage, and lifecycle semantics for digital objects. An SDLP object is a structured instance with a verifiable identity, a deterministic lifecycle, and an environment binding that governs how the object may be activated, transformed, or copied. SDLP generalizes concepts familiar from OAuth—identity, introspection, environment validation, and lifecycle transitions—and applies them to digital objects rather than authorization artifacts. Unlike ordinary files, SDLP objects do not rely on user intent or discretionary policy; their behavior is determined entirely by lifecycle rules and environment constraints. Copying an SDLP object does not produce a second instance of the same object. For identity‑bound objects (e.g., sealed digital collectibles), a copied byte sequence fails identity validation and cannot activate in any compliant environment. For entertainment media and other copy‑permitted classes, copying is a lifecycle transition: the copied bytes instantiate a new child object with its own SDLP identifier, lineage entry, and environment binding. SDLP does not prevent copying; it ensures that copying results in either a non‑functional duplicate or a valid child object, depending on the object’s class. SDLP objects maintain lineage across all lifecycle transitions. Environment validation ensures that each transition—activation, copying, transformation, or sealing—occurs only in a compliant environment. These mechanisms provide deterministic lifecycle behavior even in the presence of operational error, misconfiguration, or malicious activity. 2. Terminology The following terms are used throughout this document. SDLP Object A digital object that carries SDLP-defined metadata including identity, lifecycle state, lineage, and environment constraints. An SDLP object is activated, transformed, validated, and retired according to the rules defined in this protocol. Object Identity A unique identifier assigned to an SDLP object at issuance. Identity is validated by compliant environments prior to activation or transformation. Identity validation is analogous to OAuth token introspection. Lifecycle State The current operational state of an SDLP object. Lifecycle states include: "issued", "active", "transformed", "expired", "revoked", and "destroyed". Lifecycle transitions are governed by SDLP rules and validated by compliant environments. Lineage Metadata describing the ancestry of an SDLP object. Lineage records the issuer, issuance time, and any transformations that produced descendant objects. Lineage is preserved across transformations and validated by compliant environments. Environment A system, application, or service capable of validating SDLP object identity, evaluating lifecycle state, enforcing transition rules, and performing transformations. Environments must implement SDLP-compliant behavior to activate or transform objects. Activation The process by which an environment validates an SDLP object’s identity, evaluates its lifecycle state, and authorizes its use. Activation is analogous to the acceptance of an OAuth token by a resource server. Transformation A state transition that produces a descendant SDLP object with updated lifecycle metadata and preserved lineage. Transformations are analogous to OAuth token derivation or token exchange. Introspection The process by which an environment evaluates an SDLP object’s identity, lineage, lifecycle state, and constraints. SDLP introspection is conceptually similar to OAuth token introspection but applies to digital objects rather than access tokens. Constraint A rule limiting where or how an SDLP object may be activated or transformed. Constraints may include environment identifiers, permitted lifecycle transitions, or other protocol-defined restrictions. 3. Object Identity Every SDLP object carries a unique identity assigned at issuance. Object identity is the foundational element of SDLP lifecycle governance. Identity determines whether an object may be activated, transformed, introspected, or retired by a compliant environment. SDLP object identity is conceptually similar to the identity of an OAuth access token. As with OAuth tokens, the bytes of an SDLP object may be copied, but the identity cannot be duplicated. A copied object fails identity validation and cannot be activated by any compliant environment. 3.1. Identity Structure SDLP object identity consists of protocol-defined metadata that includes: * A globally unique object identifier. * Issuer information identifying the environment that created the object. * Issuance timestamp. * Lifecycle state at issuance. * Lineage root (the initial ancestor of the object). The identity structure is immutable. Transformations may produce descendant objects, but the identity of the original object does not change. 3.2. Identity Validation Identity validation is performed by compliant environments prior to activation or transformation. Validation includes: * Confirming that the object identifier is well-formed. * Verifying that the object was issued by a recognized environment. * Ensuring that the object has not been revoked or destroyed. * Confirming that the object’s lineage metadata is intact. * Evaluating whether the object’s lifecycle state permits the requested operation. Identity validation is analogous to OAuth token introspection. An environment must validate identity before accepting or transforming an object. 3.3. Identity and Copying SDLP does not prevent copying of object bytes. However, copying does not produce a second valid object. A copied object: * Retains the original bytes. * Fails identity validation. * Cannot be activated. * Cannot be transformed. * Cannot progress through the lifecycle. SDLP enforces lifecycle behavior through identity validation rather than through access control or rights management. Copying is allowed, but copied objects do not function. 3.4. Identity and Lineage Identity is tightly coupled with lineage. The identity of an object establishes the root of its lineage tree. Descendant objects inherit lineage metadata but receive new identities. Identity validation ensures that lineage is preserved and that transformations produce legitimate descendants rather than unauthorized copies. 4. Lifecycle Semantics SDLP defines a deterministic lifecycle for digital objects. Each object carries an identity, a lineage entry, and an environment binding. Lifecycle transitions occur only when the environment satisfies the validation rules associated with the object’s class. SDLP objects fall into two broad categories: * Identity‑bound objects: These objects have a sealed identity and cannot produce functional copies. Copying the bytes yields a duplicate that fails identity validation and cannot activate or progress through the lifecycle. * Copy‑permitted objects: These objects allow copying as a lifecycle transition. Copying produces a new child object with a new SDLP identifier, a lineage reference to the parent, and a fresh environment binding. Entertainment media, courseware, and other distributable content fall into this category. Lifecycle transitions include: * Activation: The environment validates the object’s identity and binding before allowing use. * Copy: For copy‑permitted objects, the environment instantiates a new child object with inherited metadata and a new SDLP identifier. For identity‑bound objects, the copied bytes cannot activate. * Transformation: The environment produces a new object derived from the parent, with updated lineage and lifecycle state. * Sealing: The environment finalizes the object, preventing further lifecycle transitions except those explicitly permitted by class rules. Each transition updates the object’s lineage, ensuring that SDLP objects maintain a verifiable history across all environments and operational contexts. 5. Lineage Model SDLP defines a lineage model that records the ancestry of digital objects as they undergo protocol-defined transformations. Lineage provides a verifiable history of how an object was created, how it has changed, and which environments performed those changes. The lineage model is conceptually similar to OAuth token derivation and token exchange, where a new token is produced based on an existing token. SDLP generalizes this concept to digital objects and ensures that lineage is preserved across all transformations. 5.1. Lineage Structure Each SDLP object carries lineage metadata that includes: * The identity of the issuing environment. * The issuance timestamp. * The identity of the parent object, if any. * A record of transformations performed on the object. * The environment identifiers of systems that performed those transformations. Lineage metadata is immutable once written. Descendant objects may append new lineage entries, but existing entries cannot be altered. 5.2. Lineage Preservation When an SDLP object is transformed, the resulting descendant object inherits the lineage of its parent. The descendant: * Receives a new identity. * Preserves the complete lineage of the parent. * Appends a new lineage entry describing the transformation. * Records the environment that performed the transformation. Lineage preservation ensures that compliant environments can verify the ancestry of any object and determine whether it was produced through legitimate transformations. 5.3. Lineage Validation Prior to activation or transformation, environments MUST validate the lineage of an SDLP object. Lineage validation includes: * Confirming that the lineage chain is intact and well-formed. * Ensuring that each transformation was performed by a recognized environment. * Verifying that no lineage entry has been removed or altered. * Evaluating whether the lineage permits the requested operation. Lineage validation is conceptually similar to validating the claims within a structured OAuth token, but applies to digital objects rather than authorization artifacts. 5.4. Lineage and Copying Copying an SDLP object does not produce a second instance of the same object. SDLP distinguishes between two object classes: * Identity-bound objects: Copying the bytes yields a duplicate that fails identity validation and cannot activate. These objects do not produce functional children, and their lineage does not extend through copying. * Copy-permitted objects (e.g., entertainment media): Copying is a lifecycle transition. The copied bytes instantiate a new child object with a new SDLP identifier, a lineage reference to the parent, and a fresh environment binding. Copying extends lineage and produces a new descendant object. SDLP does not prevent copying; it ensures that copying results in either a non-functional duplicate or a valid child object, depending on the object’s class. 5.5. Lineage and Descendant Objects Descendant objects form a lineage tree rooted at the original object. Each descendant: * Has its own identity. * Inherits the lineage of its parent. * Appends a new lineage entry describing the transformation or copy. * May itself be transformed or copied, producing further descendants. This lineage tree provides a complete, verifiable history of all transformations and copy events performed on an object. Environments may use lineage to determine whether a descendant object is legitimate, whether it was produced by authorized environments, and whether it may be activated or further transformed. 6. Environment Validation SDLP relies on compliant environments to validate object identity, evaluate lifecycle state, enforce transition rules, and preserve lineage. Environment validation is the mechanism through which SDLP ensures that digital objects behave consistently across systems, platforms, and deployments. Environment validation is conceptually similar to OAuth resource servers validating access tokens. In OAuth, a resource server evaluates a token’s issuer, claims, expiry, and revocation status before allowing access. SDLP generalizes this model to digital objects, requiring environments to validate identity, lineage, lifecycle state, and constraints before activating or transforming an object. 6.1. Environment Responsibilities A compliant environment MUST perform the following actions prior to activation or transformation: * Validate the object’s identity. * Validate the object’s lineage chain. * Validate the object’s lifecycle state. * Evaluate any constraints associated with the object. * Enforce legal lifecycle transitions. * Reject illegal or unauthorized transitions. * Record transformations in lineage metadata. These responsibilities ensure that SDLP objects behave consistently regardless of where they are activated or transformed. 6.2. Identity Validation Environments MUST validate object identity before activation or transformation. Identity validation includes: * Confirming that the object identifier is well-formed. * Verifying that the object was issued by a recognized environment. * Ensuring that the object has not been revoked or destroyed. * Confirming that the object’s identity metadata is intact. Identity validation is analogous to OAuth token introspection. 6.3. Lineage Validation Environments MUST validate lineage to ensure that the object was produced through legitimate transformations. Lineage validation includes: * Confirming that the lineage chain is intact. * Verifying that each transformation was performed by a recognized environment. * Ensuring that no lineage entry has been removed or altered. Lineage validation is conceptually similar to validating structured claims within an OAuth token. 6.4. Lifecycle Validation Environments MUST validate lifecycle state prior to activation or transformation. Lifecycle validation includes: * Confirming that the object is not expired. * Confirming that the object is not revoked or destroyed. * Ensuring that the requested operation is permitted for the current lifecycle state. Lifecycle validation is analogous to OAuth token expiry and revocation checks. 6.5. Constraint Evaluation SDLP objects may include constraints that limit where or how they may be activated or transformed. Environments MUST evaluate constraints prior to activation or transformation. Constraints may include: * Environment identifiers. * Permitted lifecycle transitions. * Transformation restrictions. * Operational limitations. Constraint evaluation ensures that SDLP objects behave consistently across environments. 6.6. Rejection of Invalid Objects Environments MUST reject objects that fail identity, lineage, lifecycle, or constraint validation. Rejected objects: * Cannot be activated. * Cannot be transformed. * Cannot progress through the lifecycle. SDLP enforces object behavior through validation rather than through access control or rights management. Copying is allowed, but copied objects do not function. 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. 23. References 23.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749. [RFC7662] Richer, J. and M. Jones, "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662. 23.2. Informative References [SDLP-SEC-ARCH] Norton, M., "SDLP Security Architecture", Work in Progress, draft-norton-sdlp-sec-arch-00. [SDLP-IDENTITY] Norton, M., "SDLP Identity Model", Work in Progress, draft-norton-sdlp-identity-00. [SDLP-LIFECYCLE] Norton, M., "SDLP Lifecycle Specification", Work in Progress, draft-norton-sdlp-lifecycle-00. [SDLP-OBJ-FORMAT] Norton, M., "SDLP Object Format", Work in Progress, draft-norton-sdlp-obj-format-00. [RFC6819] Lodderstedt, T., Bradley, J., and N. Sakimura, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819. 24. Acknowledgments The author thanks the members of the OAuth community whose work established the identity, introspection, and lifecycle concepts generalized by SDLP. Their contributions provided the architectural foundation upon which this document is built. The author also acknowledges the feedback provided by early reviewers, implementers, and independent contributors whose discussions helped refine the SDLP object model, lifecycle semantics, and environment‑validation framework. 25. Author’s Address M. Norton Independent Email: mark433norton@gmail.com Appendix A. Rationale This appendix provides background context and design rationale for the architectural choices made in SDLP. The intent is to document the motivations, constraints, and conceptual foundations that informed the SDLP object model, lifecycle semantics, and environment‑validation framework. SDLP generalizes concepts familiar to OAuth implementers—identity, lifecycle, introspection, and environment constraints—and applies them to digital objects rather than authorization artifacts. This approach enables consistent lifecycle behavior across heterogeneous systems without relying on user intent, discretionary policy, or external administrative controls. The architectural model prioritizes deterministic lifecycle behavior, verifiable lineage, and environment‑validated transitions. These principles ensure that SDLP objects maintain integrity even in the presence of operational error, misconfiguration, or malicious activity.