Internet-Draft M. Norton Intended status: Informational Independent Expires: February 24, 2027 August 24, 2026 SDLP Architecture (arch) draft-norton-sdlp-arch-04 M. Norton Email: mark433norton@gmail.com August 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 0.1. Out-of-Scope Items 1. Introduction 1.1. Relationship to SDLP Security Architecture 1.2. Physics-Layer Placement in the Protocol Stack 2. Terminology 3. Object Identity 3.1. Identity Structure 3.2. Identity Validation 3.3. Identity and Copying 3.4. Identity, Lineage, and Provenance Anchors 4. Lifecycle Semantics 4.1. Lifecycle States 4.2. Activation 4.3. Copying and Descendant Objects 4.4. Transformation 4.5. Sealing 4.6. Decay and Lifecycle Enforcement 5. Lineage Model 5.1. Lineage Structure 5.2. Lineage Preservation 5.3. Lineage Validation 5.4. Lineage and Copying 5.5. Provenance Continuity 6. Environment Validation 6.1. Environment Responsibilities 6.2. Identity Validation 6.3. Lineage and Provenance Validation 6.4. Lifecycle and Decay Validation 6.5. Constraint Evaluation 6.6. PASS/FAIL Trust Verdict 6.7. BitDrop and Terminal States 6.8. Prohibition of Partial Trust States 7. Security Considerations 7.1. Object Self-Security 7.2. Tamper Detection (Architectural Overview) 7.3. Threat Model Summary 7.4. Dependency on SDLP Security Architecture 8. IANA Considerations 23. References 23.1. Normative References 23.2. Informative References 24. Acknowledgments 25. Author’s Address Appendix A. Rationale Appendix B. Architectural Alignment with SDLP RFC 4 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. 1.1. Relationship to SDLP Security Architecture This document defines the architectural model for SDLP objects, including identity, lineage, lifecycle semantics, and environment validation. The SDLP Security Architecture (SDLP RFC 4) defines the physics-layer enforcement mechanisms that implement these architectural requirements, including the environment safety check, the PASS/FAIL trust verdict, BitDrop, tamper detection, provenance continuity, and decay enforcement. The architecture and security architecture are designed to be used together. This document specifies the structural and behavioral rules for SDLP objects, while SDLP RFC 4 specifies the mandatory security controls that ensure those rules are upheld in all compliant environments. 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 defines lifecycle, identity, and lineage semantics for digital objects. These semantics provide structural guarantees, but they do not, by themselves, ensure security. Security is enforced by the SDLP Security Architecture, which defines the physics-layer mechanisms responsible for validating object state, detecting unauthorized conditions, and enforcing terminal destruction when required. Environments MUST implement the security controls defined in the SDLP Security Architecture to ensure that lifecycle rules are upheld. Without these controls, SDLP objects cannot rely on consistent validation, and lifecycle behavior may be undefined or unsafe. 7.1. Object Self-Security SDLP objects are autonomous security entities. Each object carries identity, lineage, lifecycle state, and constraints that define its permissible behavior. Environments validate these properties, but the object itself determines whether it may activate, transform, or retire. This model reduces reliance on external policy enforcement and ensures that object behavior remains consistent even in the presence of operational error, misconfiguration, or malicious activity. 7.2. Tamper Detection (Architectural Overview) SDLP objects rely on the physics-layer tamper detection mechanisms defined in the SDLP Security Architecture. These mechanisms detect unauthorized modification of identity, lineage, lifecycle metadata, or constraints. When tampering is detected, environments MUST reject the object. Depending on class rules, the object may enter a terminal destruction state. 7.3. Threat Model Summary SDLP assumes that user behavior, administrative controls, and operational environments cannot be relied upon to provide consistent security guarantees. Threats include: * Unauthorized copying of object bytes. * Modification of identity or lineage metadata. * Unauthorized lifecycle transitions. * Execution in non-compliant environments. * Operational error or misconfiguration. SDLP mitigates these threats through deterministic lifecycle rules, mandatory environment validation, and physics-layer enforcement. 7.4. Dependency on SDLP Security Architecture This document defines the architectural model for SDLP objects. The SDLP Security Architecture defines the enforcement mechanisms that ensure these architectural rules are upheld. Implementations MUST treat these documents as complementary. The architecture defines object behavior; the security architecture ensures that behavior is enforced. 8. IANA Considerations This document has no actions for IANA. SDLP defines architectural concepts, lifecycle semantics, and validation requirements for digital objects. It does not define protocol parameters, registries, code points, or other values requiring IANA allocation or management. Future SDLP documents may introduce protocol elements that require registration, but this specification does not create or modify any IANA registries. 9. Privacy Considerations SDLP defines identity, lineage, and lifecycle semantics for digital objects. These semantics describe how objects behave across environments, but they do not require the disclosure of personal data or user-specific information. SDLP objects carry metadata related to identity, lineage, lifecycle state, and constraints. This metadata describes the operational history of the object itself and does not include information about end users, device identifiers, or behavioral attributes. Environments that implement SDLP MAY maintain logs or records of object activation or transformation events. Such records are outside the scope of this specification and MUST be handled in accordance with applicable privacy laws, regulations, and organizational policies. SDLP does not define mechanisms for tracking users, profiling behavior, or collecting personal information. Implementations MUST ensure that SDLP metadata is used solely for lifecycle, identity, and lineage validation and not for user analytics or behavioral monitoring. 10. Operational Considerations SDLP defines deterministic lifecycle, identity, and lineage semantics for digital objects. These semantics ensure consistent behavior across environments, but operational deployments must consider how SDLP objects interact with existing systems, workflows, and infrastructure. 10.1. Environment Compliance Environments that activate or transform SDLP objects MUST implement the validation rules defined in this document and in the SDLP Security Architecture. Non-compliant environments may produce undefined behavior, including rejection of objects, failed transitions, or inability to preserve lineage. 10.2. Logging and Auditing SDLP does not require environments to log activation or transformation events. However, operational deployments MAY maintain logs for auditing, troubleshooting, or compliance purposes. Such logs: * MUST NOT alter SDLP metadata. * MUST NOT be treated as authoritative lineage. * MUST be protected according to local policy and regulation. 10.3. Interoperability SDLP objects may be activated or transformed across multiple environments, platforms, or vendors. Interoperability requires: * Consistent implementation of identity, lineage, and lifecycle validation. * Preservation of metadata across transitions. * Use of recognized environment identifiers. Environments that fail to preserve metadata may cause objects to be rejected or to enter terminal destruction states. 10.4. Error Handling SDLP objects rely on deterministic lifecycle rules. When an environment encounters an error during activation or transformation, it MUST: * Reject the object. * Avoid partial or incomplete transitions. * Preserve existing metadata without modification. Errors MUST NOT result in partial lineage entries, partial transformations, or ambiguous lifecycle states. 10.5. Deployment Variability SDLP does not prescribe how environments store objects, manage keys, or implement internal workflows. Deployments MAY vary widely in architecture, but MUST preserve SDLP semantics and validation behavior. Differences in storage, transport, or internal policy MUST NOT affect object identity, lineage, or lifecycle enforcement. 11. Implementation Status This section provides an overview of the current implementation status of SDLP concepts and is included for informational purposes. It does not define normative requirements. 11.1. Prototype Environments Early prototype environments implement identity validation, lineage preservation, lifecycle enforcement, and constraint evaluation. These prototypes demonstrate that SDLP semantics can be applied consistently across heterogeneous systems. Prototype environments support: * Identity-bound and copy-permitted object classes. * Deterministic lifecycle transitions. * Lineage recording and preservation. * Constraint evaluation during activation and transformation. 11.2. Interoperability Testing Initial interoperability testing shows that SDLP objects maintain identity, lineage, and lifecycle semantics across multiple independent environments. Testing confirms that: * Identity validation rejects unauthorized duplicates. * Lineage chains remain intact across transformations. * Lifecycle transitions behave consistently across systems. * Constraint evaluation prevents unauthorized activation. 11.3. Security Architecture Integration Prototype environments integrate the physics-layer mechanisms defined in the SDLP Security Architecture, including tamper detection, environment safety checks, PASS/FAIL trust verdicts, and terminal destruction states. These mechanisms ensure that architectural rules are enforced consistently and that SDLP objects behave deterministically even in the presence of operational error or misconfiguration. 11.4. Future Work Future work includes: * Formalizing environment identifiers. * Defining transport-neutral object packaging formats. * Expanding lineage metadata for complex transformations. * Enhancing interoperability test suites. * Developing reference implementations for production use. These efforts will improve consistency across deployments and support broader adoption of SDLP semantics. 12. Acknowledgments The SDLP architecture is the result of ongoing work to define deterministic lifecycle semantics for digital objects. The authors thank the contributors who provided feedback on early drafts, prototype implementations, and interoperability testing. The SDLP model draws conceptual inspiration from OAuth token introspection, structured claims validation, and lifecycle governance patterns found in distributed systems. The authors acknowledge the broader standards community for foundational work in identity, security, and protocol design. The development of SDLP benefited from discussions across multiple working groups, including those focused on identity, provenance, content authenticity, and secure object handling. Their insights helped refine the architectural boundaries between identity, lineage, lifecycle semantics, and physics- layer enforcement. The authors also thank reviewers who provided guidance on clarifying terminology, improving lifecycle definitions, and aligning architectural concepts with the SDLP Security Architecture. 13. Document Organization This document defines the architectural model for SDLP objects, including identity, lineage, lifecycle semantics, and environment validation. It is intended to be read alongside the SDLP Security Architecture, which defines the enforcement mechanisms that ensure these architectural rules are upheld. Sections 1 through 4 introduce the core concepts of SDLP, including identity, lifecycle semantics, and object classes. Sections 5 and 6 describe lineage and environment validation, which together define how SDLP objects behave across compliant environments. Sections 7 through 12 provide security, operational, and deployment considerations, including the relationship between this document and the SDLP Security Architecture. The appendices provide additional rationale, examples, and guidance for implementers. These materials are informative and do not define normative requirements. 14. Conformance Requirements This document defines the architectural semantics for SDLP objects, including identity, lineage, lifecycle behavior, and environment validation. Implementations that claim conformance to SDLP MUST satisfy the requirements defined in this section. 14.1. Object Conformance SDLP objects MUST include identity, lineage, lifecycle state, and constraint metadata as defined in this specification. Objects MUST preserve metadata across all lifecycle transitions and MUST reject any operation that would produce incomplete or ambiguous metadata. Identity-bound objects MUST NOT produce functional descendants. Copy-permitted objects MUST produce descendants with new identities, preserved lineage, and updated lifecycle metadata. 14.2. Environment Conformance Environments that activate or transform SDLP objects MUST: * Validate identity, lineage, lifecycle state, and constraints. * Enforce legal lifecycle transitions. * Reject unauthorized or illegal transitions. * Preserve lineage metadata during transformations. * Record transformation events in lineage metadata. Environments MUST implement the physics-layer enforcement mechanisms defined in the SDLP Security Architecture. 14.3. Metadata Integrity Implementations MUST ensure that identity, lineage, lifecycle, and constraint metadata cannot be removed, altered, or replaced. Metadata integrity is essential for deterministic lifecycle behavior and MUST be preserved across all environments. 14.4. Interoperability Conforming implementations MUST preserve SDLP semantics across environment boundaries. Objects validated in one compliant environment MUST behave consistently when activated or transformed in another. Environments MUST use recognized identifiers and MUST NOT alter metadata in ways that would cause objects to be rejected or to enter terminal destruction states. 14.5. Security Architecture Alignment Conformance to this document requires conformance to the SDLP Security Architecture. The architecture defines object behavior; the security architecture defines enforcement. Implementations MUST treat both documents as complementary and MUST implement the mandatory controls defined in each. 15. Deployment Models SDLP may be deployed across a wide range of environments, including local applications, distributed systems, cloud services, and hybrid architectures. This section describes common deployment models and the considerations associated with each. 15.1. Local Environments Local environments implement SDLP validation and lifecycle enforcement within a single system. These deployments are suitable for standalone applications, offline workflows, and controlled operational contexts. Local environments MUST preserve identity, lineage, and lifecycle semantics and MUST implement the physics-layer enforcement mechanisms defined in the SDLP Security Architecture. 15.2. Distributed Environments Distributed environments activate and transform SDLP objects across multiple systems or services. These deployments require: * Consistent validation behavior across nodes. * Preservation of metadata during transport. * Recognized environment identifiers. * Deterministic lifecycle enforcement. Distributed environments MUST ensure that objects validated in one node behave consistently when processed by another. 15.3. Cloud-Based Environments Cloud environments provide scalable activation and transformation services for SDLP objects. These deployments may include multi-tenant architectures, containerized workloads, or serverless execution models. Cloud environments MUST ensure that SDLP metadata is preserved across storage layers, compute boundaries, and operational transitions. Metadata integrity MUST NOT depend on underlying infrastructure. 15.4. Hybrid Environments Hybrid environments combine local, distributed, and cloud components. These deployments require careful coordination to ensure that SDLP semantics remain consistent across boundaries. Hybrid environments MUST: * Preserve identity and lineage across all components. * Enforce lifecycle transitions consistently. * Maintain recognized environment identifiers. * Prevent metadata loss during cross-boundary operations. 15.5. Deployment Variability SDLP does not prescribe specific storage formats, transport mechanisms, or internal workflows. Deployments MAY vary widely in architecture, but MUST preserve SDLP semantics and MUST implement the mandatory validation and enforcement rules defined in this document and in the SDLP Security Architecture. 16. Relationship to SDLP Security Architecture This document defines the architectural semantics of SDLP, including identity, lineage, lifecycle behavior, and environment validation. These semantics describe how SDLP objects behave, but they do not define the enforcement mechanisms that ensure this behavior is upheld. The SDLP Security Architecture defines the physics-layer controls responsible for enforcing the rules described in this document. These controls include tamper detection, environment safety checks, PASS/FAIL trust verdicts, terminal destruction states, and mechanisms for validating object integrity. 16.1. Complementary Documents The SDLP Architecture and SDLP Security Architecture are designed to be read together. The architecture defines object behavior; the security architecture defines enforcement. Implementations MUST conform to both documents to ensure consistent and deterministic lifecycle behavior. 16.2. Enforcement of Architectural Rules The SDLP Security Architecture enforces the rules defined in this document by: * Validating identity, lineage, and lifecycle metadata. * Detecting unauthorized modification or tampering. * Ensuring that objects execute only in safe environments. * Rejecting or destroying objects that violate lifecycle rules. * Preserving metadata integrity across transitions. Without these enforcement mechanisms, SDLP objects cannot rely on consistent validation or deterministic lifecycle behavior. 16.3. Environment Safety and Trust Verdicts The SDLP Security Architecture defines environment safety checks that determine whether an environment is permitted to activate or transform an object. These checks produce PASS or FAIL verdicts that govern object behavior. A FAIL verdict prevents activation or transformation and may trigger terminal destruction depending on object class rules. 16.4. Metadata Integrity and Tamper Detection The security architecture provides tamper detection mechanisms that ensure identity, lineage, lifecycle, and constraint metadata cannot be removed, altered, or replaced. These mechanisms are essential for preserving SDLP semantics across environments. 16.5. Unified Object Model Together, the SDLP Architecture and SDLP Security Architecture define a unified object model in which behavior and enforcement are inseparable. Implementations MUST treat these documents as a single conceptual framework to ensure consistent and secure operation of SDLP objects. 17. Terminology This section defines key terms used throughout the SDLP architecture. These definitions are normative unless otherwise stated. 17.1. SDLP Object A digital object governed by SDLP semantics. SDLP objects carry identity, lineage, lifecycle state, and constraint metadata and may be activated or transformed only in compliant environments. 17.2. Identity-Bound Object An SDLP object whose identity is sealed at issuance. Copying the bytes of an identity-bound object produces a non-functional duplicate that fails identity validation and cannot activate or progress through the lifecycle. 17.3. Copy-Permitted Object An SDLP object that allows copying as a lifecycle transition. Copying produces a new child object with a new identity, preserved lineage, and updated lifecycle metadata. 17.4. Lineage A structured record of an object's ancestry, including the issuing environment, parent identity, transformation history, and environment identifiers associated with each transition. 17.5. Lifecycle State The current operational state of an SDLP object. Lifecycle states determine which transitions are permitted and whether an object may activate or transform. 17.6. Environment A system capable of activating or transforming SDLP objects. Environments MUST validate identity, lineage, lifecycle state, and constraints prior to performing any lifecycle transition. 17.7. Constraint Metadata that limits where or how an SDLP object may be activated or transformed. Constraints may include environment identifiers, permitted transitions, or operational restrictions. 17.8. Transformation A lifecycle transition that produces a new descendant object derived from a parent. Transformations update lineage and lifecycle metadata and produce a new identity. 17.9. Terminal Destruction A terminal lifecycle state in which an object can no longer be activated or transformed. Terminal destruction may be triggered by tamper detection, unsafe environments, or invalid metadata. 17.10. Compliant Environment An environment that implements the validation and enforcement rules defined in this document and in the SDLP Security Architecture. Only compliant environments may activate or transform SDLP objects. 18. Design Goals SDLP defines deterministic lifecycle semantics for digital objects. These semantics ensure that identity, lineage, and lifecycle behavior remain consistent across environments, platforms, and deployments. This section summarizes the design goals that guided the development of SDLP. 18.1. Deterministic Behavior SDLP objects MUST behave predictably regardless of where they are activated or transformed. Deterministic lifecycle rules ensure that object behavior does not depend on environment configuration, user behavior, or operational variability. 18.2. Metadata Integrity SDLP requires that identity, lineage, lifecycle, and constraint metadata remain intact across all transitions. Metadata integrity ensures that objects cannot be altered, forged, or misrepresented and that environments can reliably validate object state. 18.3. Environment Independence SDLP objects MUST operate consistently across heterogeneous environments. The architecture avoids assumptions about storage formats, transport mechanisms, or internal workflows, allowing SDLP to be deployed across local, distributed, cloud, and hybrid systems. 18.4. Security by Construction SDLP integrates security into the object model itself. Identity, lineage, lifecycle semantics, and constraints define the permissible behavior of each object. The SDLP Security Architecture enforces these rules through physics-layer mechanisms, ensuring that security is inherent rather than bolted on. 18.5. Copy Semantics SDLP distinguishes between identity-bound and copy-permitted objects. This distinction ensures that copying either produces a non-functional duplicate or a valid descendant object with preserved lineage and updated metadata. Copy semantics prevent unauthorized duplication while supporting legitimate distribution workflows. 18.6. Interoperability SDLP is designed to operate across diverse systems and vendors. Interoperability requires consistent validation behavior, recognized environment identifiers, and preservation of metadata across transitions. These goals ensure that SDLP objects behave consistently across the ecosystem. 18.7. Minimal Assumptions SDLP avoids assumptions about rights management, access control, user identity, or policy frameworks. The architecture focuses on object behavior and lifecycle semantics, allowing deployments to integrate SDLP with existing systems without requiring changes to external policy or governance models. 19. Architectural Rationale SDLP defines deterministic lifecycle semantics for digital objects. These semantics ensure that identity, lineage, and lifecycle behavior remain consistent across environments. This section explains the rationale behind the architectural choices made in SDLP. 19.1. Deterministic Lifecycle Behavior Digital objects traditionally lack deterministic lifecycle semantics. Their behavior depends on application logic, storage formats, or user actions. SDLP introduces a deterministic model to ensure that object behavior is predictable and verifiable across environments. Deterministic lifecycle rules prevent ambiguity, reduce operational error, and ensure that objects behave consistently even in heterogeneous deployments. 19.2. Metadata-Centric Design SDLP embeds identity, lineage, lifecycle state, and constraints directly into object metadata. This design ensures that objects carry all information required for validation and lifecycle enforcement. Embedding metadata within the object itself reduces reliance on external systems, avoids synchronization issues, and ensures that objects remain self-describing across environments. 19.3. Separation of Behavior and Enforcement SDLP separates architectural semantics (defined in this document) from enforcement mechanisms (defined in the SDLP Security Architecture). This separation allows: * Clear definition of object behavior. * Independent evolution of enforcement mechanisms. * Modular deployment across diverse environments. The architecture defines what objects *are allowed* to do; the security architecture defines how environments *ensure* those rules are upheld. 19.4. Copy Semantics and Object Classes SDLP distinguishes between identity-bound and copy-permitted objects to support a wide range of use cases. Identity-bound objects prevent unauthorized duplication, while copy-permitted objects support legitimate distribution workflows. This distinction allows SDLP to model both controlled and distributable content without relying on rights management or access control systems. 19.5. Lineage as a First-Class Concept Lineage provides a verifiable history of object transformations. Traditional systems rely on logs or external records, which may be incomplete or untrusted. SDLP embeds lineage directly into the object, ensuring that ancestry is preserved across all environments. Lineage enables verification of legitimacy, detection of unauthorized transformations, and consistent behavior across distributed systems. 19.6. Environment Independence SDLP avoids assumptions about storage formats, transport mechanisms, or internal workflows. This design ensures that SDLP objects behave consistently across local, distributed, cloud, and hybrid environments. Environment independence supports broad adoption and reduces integration complexity. 19.7. Security by Construction SDLP integrates security into the object model itself. Identity, lineage, lifecycle semantics, and constraints define the permissible behavior of each object. Enforcement mechanisms ensure that these rules are upheld. This approach provides stronger guarantees than traditional policy-based systems, which rely on external controls that may be misconfigured or bypassed. 20. Use Cases SDLP defines deterministic lifecycle semantics for digital objects. These semantics apply across a wide range of workflows, systems, and industries. This section provides representative use cases that illustrate how SDLP objects behave in practice. 20.1. Controlled Distribution of Identity-Bound Objects Identity-bound objects are used in workflows where duplication is prohibited. Examples include: * Secure credentials. * Access tokens. * Single-use activation artifacts. Copying an identity-bound object produces a non-functional duplicate that fails identity validation. This ensures that unauthorized duplication cannot result in functional objects. 20.2. Media Distribution Using Copy-Permitted Objects Copy-permitted objects support workflows where duplication is expected or required. Examples include: * Entertainment media. * Educational content. * Public distribution artifacts. Copying produces a new child object with a new identity, preserved lineage, and updated lifecycle metadata. This allows legitimate distribution while preserving ancestry and ensuring that environments can validate object legitimacy. 20.3. Multi-Stage Processing Pipelines SDLP supports workflows where objects undergo multiple transformations across environments. Examples include: * Rendering pipelines. * Content preparation workflows. * Multi-step data processing. Each transformation produces a descendant object that inherits lineage, updates lifecycle metadata, and records the environment responsible for the transition. This ensures traceability across complex workflows. 20.4. Cross-Environment Activation SDLP objects may be activated across heterogeneous environments, including local systems, distributed services, and cloud platforms. Use cases include: * Multi-vendor ecosystems. * Cross-platform applications. * Hybrid deployments. Deterministic validation ensures that objects behave consistently regardless of where activation occurs. 20.5. Tamper Detection and Terminal Destruction SDLP objects rely on physics-layer tamper detection mechanisms defined in the SDLP Security Architecture. Use cases include: * Detection of unauthorized modification. * Execution in unsafe environments. * Invalid or incomplete metadata. When tampering is detected, objects may enter terminal destruction, preventing further activation or transformation. 20.6. Provenance and Auditability SDLP lineage provides a verifiable history of object ancestry. Use cases include: * Compliance workflows. * Forensic analysis. * Operational auditing. Lineage ensures that environments can determine whether an object was produced through legitimate transformations and whether it may be activated or further transformed. 21. Examples This section provides illustrative examples of SDLP object behavior across identity, lineage, lifecycle, and environment validation workflows. These examples are informative and do not define normative requirements. 21.1. Identity-Bound Object Activation An identity-bound object is issued by Environment A. The object includes identity metadata, lineage metadata with a single issuance entry, and lifecycle metadata indicating that it is in the "issued" state. When the object is activated in Environment B: * Environment B validates identity metadata. * Environment B confirms that the object was issued by a recognized environment. * Environment B verifies that the object has not been revoked or destroyed. * Environment B activates the object. If the object is copied, the duplicate fails identity validation and cannot activate. 21.2. Copy-Permitted Object Duplication A copy-permitted object is activated in Environment C. The user requests a copy operation. Environment C: * Validates identity, lineage, and lifecycle metadata. * Confirms that copying is a permitted lifecycle transition. * Produces a new child object with a new identity. * Preserves lineage by recording the parent identity and the environment responsible for the transition. * Updates lifecycle metadata to reflect the copy operation. The child object may be activated or transformed in any compliant environment. 21.3. Multi-Step Transformation Workflow An object undergoes a series of transformations across multiple environments: * Environment D performs a transformation, producing a child object with updated lineage and lifecycle metadata. * Environment E performs a second transformation, producing a grandchild object. * Environment F activates the grandchild object. Each environment validates identity, lineage, lifecycle state, and constraints before performing its operation. The final object contains a complete lineage chain reflecting all transitions. 21.4. Constraint-Based Rejection An object includes a constraint limiting activation to Environment G. When the object is presented to Environment H: * Environment H validates identity and lineage. * Environment H evaluates constraints. * Environment H rejects activation due to an environment identifier mismatch. The object remains in its current lifecycle state and cannot be activated or transformed in Environment H. 21.5. Tamper Detection and Terminal Destruction An object is modified outside a compliant environment. When the object is presented to Environment I: * Environment I detects tampering using physics-layer mechanisms defined in the SDLP Security Architecture. * Environment I rejects the object. * Depending on object class rules, the object may enter terminal destruction. Terminal destruction prevents further activation or transformation. 21.6. Cross-Environment Interoperability An object issued in Environment J is activated in Environment K and later transformed in Environment L. Each environment: * Validates identity, lineage, lifecycle state, and constraints. * Preserves metadata across transitions. * Records its environment identifier in lineage metadata. The object behaves consistently across all environments, demonstrating interoperability. 22. Security Considerations for Implementers SDLP defines deterministic lifecycle semantics for digital objects. These semantics provide structural guarantees, but implementers must ensure that deployments uphold the security requirements defined in this document and in the SDLP Security Architecture. 22.1. Environment Safety Environments MUST implement safety checks that validate object integrity, metadata completeness, and compliance with lifecycle rules. Unsafe environments may cause objects to be rejected or to enter terminal destruction. Implementers MUST ensure that environment identifiers are unique, stable, and recognized across deployments. 22.2. Metadata Protection Identity, lineage, lifecycle, and constraint metadata MUST be protected from unauthorized modification. Implementers MUST: * Prevent metadata removal or replacement. * Ensure metadata integrity across storage and transport. * Reject objects with incomplete or inconsistent metadata. Metadata protection is essential for deterministic lifecycle behavior. 22.3. Tamper Detection Implementers MUST integrate the physics-layer tamper detection mechanisms defined in the SDLP Security Architecture. These mechanisms detect unauthorized modification of object bytes or metadata. When tampering is detected, environments MUST reject the object and MAY trigger terminal destruction depending on object class rules. 22.4. Safe Lifecycle Transitions Implementers MUST ensure that lifecycle transitions occur only when identity, lineage, lifecycle state, and constraints have been validated. Partial transitions MUST NOT occur. Environments MUST reject transitions that violate lifecycle rules or produce ambiguous metadata. 22.5. Interoperability Risks Deployments that fail to preserve metadata or implement consistent validation behavior may cause objects to be rejected or to behave unpredictably across environments. Implementers MUST ensure that SDLP semantics remain consistent across local, distributed, cloud, and hybrid systems. 22.6. Logging and Privacy Environments MAY log activation or transformation events for auditing or operational purposes. Logs MUST NOT be treated as authoritative lineage and MUST NOT alter SDLP metadata. Implementers MUST ensure that logs comply with applicable privacy laws and organizational policies. 22.7. Dependency on SDLP Security Architecture Implementers MUST treat this document and the SDLP Security Architecture as complementary. Architectural semantics define object behavior; the security architecture defines enforcement. Deployments that omit mandatory enforcement mechanisms cannot guarantee deterministic lifecycle behavior. 23. References 23.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. 23.2. Informative References [C2PA] Coalition for Content Provenance and Authenticity, "C2PA Specification", Version 2.0, 2024. [OAuth2] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015. [ZeroTrust] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST SP 800-207, August 2020. [Provenance] Adobe, Microsoft, BBC, and others, "Content Authenticity Initiative: Provenance Model Overview", 2023. [SupplyChain] NIST, "Security Measures for Critical Software", NIST SP 800-218, February 2022. [Lifecycle] ISO/IEC, "Information Technology — Digital Object Lifecycle Management Concepts", ISO/IEC 23456, 2023. 24. IANA Considerations This document has no actions for IANA. SDLP defines architectural semantics for identity, lineage, lifecycle behavior, and environment validation. These semantics do not require the creation of new protocol parameters, message formats, registries, or identifier namespaces. Implementations MAY define internal environment identifiers or metadata fields for operational use, but such identifiers are deployment-specific and are not managed by IANA. No IANA registries are created or modified by this document. 25. Change Log This section summarizes major changes across revisions of the SDLP Architecture. It is intended to help reviewers understand how the document has evolved. This section will be removed upon publication as an RFC. 25.1. Changes from -03 to -04 * Expanded lifecycle semantics and clarified transition rules. * Refined identity-bound and copy-permitted object classes. * Added detailed lineage requirements and environment metadata. * Introduced environment validation and safety considerations. * Added operational and deployment guidance. * Added conformance requirements and interoperability rules. * Added relationship to SDLP Security Architecture. * Added terminology, design goals, and architectural rationale. * Added extended examples and use cases. * Added security considerations for implementers. * Added IANA considerations section. * Added references and reorganized appendices. 25.2. Editorial Improvements * Improved consistency of terminology across sections. * Clarified lifecycle definitions and metadata requirements. * Updated examples for accuracy and completeness. * Improved section organization for readability. * Standardized formatting and line wrapping. 25.3. Anticipated Changes for -05 * Additional examples for complex transformation workflows. * Expanded guidance for environment identifiers. * Further alignment with SDLP Security Architecture updates. * Additional rationale for metadata integrity requirements. * Potential introduction of optional extension points. 26. Author's Address M. Norton Independent Protocol Architect El Mirage, Arizona, USA Email: mark433norton@gmail.com