Internet-Draft M. Norton Intended status: Informational Independent Expires: January 20, 2027 July 20, 2026 SDLP Physics Specification draft-norton-sdlp-phys-00 M. Norton Independent 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 a physics layer for digital objects: a set of non-negotiable behavioral laws that govern identity stability, lineage integrity, lifecycle determinism, and irreversible state transitions. SDLP Physics establishes how object security depletes, transforms, or terminates as an object is activated, used, or shared, ensuring that each operation consumes or alters the object’s allowable state in predictable ways. These laws prevent cloning, enforce legitimate descent, bind objects to their environments, and guarantee that destruction and zeroization are final. This document specifies the core physics that underpin SDLP’s security model and define how digital objects behave across all environments and distribution paths. 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 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 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 1. Introduction 2. Terminology 3. SDLP Invariants (The Three Laws) 4. Deterministic Behavior Requirements 5. Identity Physics 6. Lifecycle Physics 7. Lineage Physics 8. Environment Physics 9. Cryptographic Physics 10. Destruction Physics 11. Security Considerations 12. IANA Considerations 13. References 14. Author’s Address 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines deterministic behavior for digital objects whose identity, lineage, and lifecycle evolve as they are activated, used, or shared. SDLP Physics specifies the non-negotiable laws that govern this behavior. These laws form the core of SDLP’s security model: object security depletes, transforms, or terminates as the object progresses through its lifecycle, ensuring that each use consumes or alters the object’s allowable state. SDLP Physics defines identity stability, transition legality, lineage integrity, environment validation requirements, cryptographic determinism, and irreversible destruction. These laws apply uniformly across all SDLP object classes and environments. They ensure that objects cannot be cloned, resurrected, or rolled back, and that descendant objects are produced only through legitimate, validated transitions. This document does not define identity structures, lifecycle models, lineage formats, or environment interfaces. Instead, it defines the physics that those models MUST obey. SDLP Physics provides the foundational enforcement layer upon which SDLP architecture, security mechanisms, and object specifications are built. 2. Terminology Physics The set of deterministic, non-negotiable laws governing SDLP object behavior, including identity stability, transition legality, lineage integrity, environment validation, and irreversible destruction. Invariant A rule that MUST hold true for all SDLP objects regardless of class, environment, or distribution model. Deterministic Transition A lifecycle transition whose outcome is fully defined by SDLP physics and cannot be altered by user intent, discretionary policy, or environmental variability. Illegal Transition A transition that violates SDLP physics and MUST be rejected by all compliant environments. Terminal State A lifecycle state from which an object cannot return, including destroyed, revoked, and expired. Zeroization The irreversible removal of sensitive material from an SDLP object, ensuring that the object cannot be rehydrated, resurrected, or reinstantiated. Identity Stability The property that an SDLP object’s identity MUST NOT change after issuance and MUST NOT be duplicated through copying or replication. Lineage Integrity The requirement that lineage MUST be complete, immutable, and append-only, with each descendant object inheriting and extending the lineage of its parent. Environment Binding The association between an SDLP object and the environment signals required to validate identity, lineage, lifecycle state, and transition legality. 3. SDLP Invariants (The Three Laws) SDLP Physics defines three fundamental invariants that govern all SDLP object behavior. These invariants apply uniformly across all object classes, environments, and distribution paths. They form the core enforcement layer that ensures identity stability, transition determinism, lineage integrity, and irreversible destruction. These laws are non-negotiable. No SDLP-compliant environment may override, bypass, or weaken them. All lifecycle transitions, lineage updates, environment validations, and cryptographic operations MUST conform to these invariants. 3.1 Identity Integrity An SDLP object’s identity MUST be unique, immutable, and non-clonable. Identity MUST NOT change after issuance, and copying the object’s bytes MUST NOT produce a second valid identity. Identity MUST bind to the object’s lineage root, lifecycle state, and environment of issuance. All transitions MUST validate identity before proceeding. 3.2 Transition Integrity All SDLP lifecycle transitions MUST be deterministic, validated, and authorized. A transition’s outcome MUST be fully defined by SDLP physics and MUST NOT depend on user intent, discretionary policy, or environmental variability. Illegal transitions—including unauthorized activation, unauthorized copying, resurrection, rollback, and rehydration—MUST be rejected by all compliant environments. 3.3 Lineage Integrity SDLP lineage MUST be complete, immutable, and append-only. Each descendant object MUST inherit the lineage of its parent and append a new lineage entry reflecting the transition that produced it. Lineage MUST NOT be truncated, rewritten, or replaced. All environments MUST validate lineage before permitting any lifecycle transition. 4. Deterministic Behavior Requirements SDLP Physics requires that all object behavior be deterministic. Every transition, lineage update, validation step, and cryptographic operation MUST produce predictable, reproducible results across all compliant environments. Determinism ensures that object security depletes, transforms, or terminates in a controlled and verifiable manner as the object is activated, used, or shared. 4.1 Deterministic Encoding SDLP objects MUST use canonical encodings. The same object, when serialized, MUST produce identical byte sequences across all environments. Canonical encoding ensures stable hashing, consistent lineage updates, and predictable transition outcomes. 4.2 Deterministic Hashing Hash operations performed on SDLP objects MUST be deterministic. Identical inputs MUST produce identical outputs across all compliant environments. Hash determinism is required for tamper detection, lineage integrity, and identity stability. 4.3 Deterministic Signatures Digital signatures applied to SDLP objects MUST be verifiable across all compliant environments. Signature generation and verification MUST be deterministic, ensuring that identity, lineage, and lifecycle state are bound consistently and cannot be forged or replayed. 4.4 Deterministic Lineage Updates Lineage updates MUST be deterministic and append-only. Given the same object state and transition type, all compliant environments MUST produce identical lineage entries. Deterministic lineage updates ensure that descendant objects reflect legitimate transitions and that lineage cannot be rewritten, truncated, or replaced. 4.5 Deterministic Transition Outcomes All lifecycle transitions MUST produce deterministic results. A transition’s outcome MUST be defined solely by SDLP physics and MUST NOT depend on user intent, discretionary policy, or environmental variability. Deterministic transitions ensure that object security depletes or terminates in predictable ways as the object is used or shared. 5. Identity Physics SDLP Physics defines the laws governing identity behavior for all SDLP objects. Identity is the foundation of object security: it determines how an object is recognized, validated, and constrained as it is activated, used, or shared. Identity MUST remain stable, MUST NOT be clonable, and MUST bind to the object’s lineage, lifecycle state, and environment of issuance. Identity physics ensures that object security depletes or transforms predictably as the object progresses through its lifecycle. Identity stability prevents unauthorized duplication, while identity binding ensures that transitions and lineage updates reflect legitimate, validated behavior. 5.1 Identity Stability An SDLP object’s identity MUST be immutable after issuance. Identity MUST NOT change as the object transitions through its lifecycle, and identity MUST NOT be replaced, rewritten, or reissued. Identity stability ensures that object behavior remains predictable and that lineage and lifecycle constraints remain enforceable. 5.2 Identity Non-Clonability Copying an SDLP object’s bytes MUST NOT produce a second valid identity. Identity MUST be bound to the object’s lineage root, environment of issuance, and lifecycle state in a manner that prevents duplication or replication. Non-clonability ensures that object security depletes or terminates as the object is used or shared, rather than being reset or multiplied through copying. 5.3 Identity Binding Identity MUST bind to the object’s lineage, lifecycle state, and environment. This binding ensures that identity validation reflects the object’s complete history and current state. Identity binding MUST be cryptographically verifiable and MUST remain stable across all compliant environments. 5.4 Identity Validation Physics Identity MUST be validated before any lifecycle transition. Validation MUST confirm identity stability, lineage integrity, and environment binding. If identity validation fails, the transition MUST be rejected and the object MUST NOT proceed. Identity validation ensures that illegal transitions—including unauthorized activation, copying, transformation, resurrection, rollback, or rehydration—are prevented by physics rather than policy. 6. Lifecycle Physics SDLP Physics defines the laws governing lifecycle behavior for all SDLP objects. Lifecycle transitions represent the ways an object may be activated, used, shared, transformed, or terminated. Each transition consumes, alters, or depletes the object’s allowable state in predictable ways. Lifecycle physics ensures that transitions are legitimate, deterministic, and irreversible when required. All lifecycle transitions MUST conform to SDLP invariants. Illegal transitions—including unauthorized activation, unauthorized copying, resurrection, rollback, and rehydration—MUST be rejected by all compliant environments. Lifecycle physics ensures that object security cannot be reset, duplicated, or bypassed through manipulation of state or environment. 6.1 Legal Transitions SDLP objects MAY undergo the following legal transitions, subject to identity validation, lineage verification, and environment binding: * Activation * Copy (when permitted by object class) * Transformation * Sealing * Destruction Each legal transition MUST be deterministic and MUST produce a predictable change in the object’s lifecycle state. Legal transitions MUST update lineage in an append-only manner and MUST preserve identity stability. 6.2 Illegal Transitions Illegal transitions violate SDLP Physics and MUST be rejected by all compliant environments. Illegal transitions include: * Unauthorized activation * Unauthorized copying * Unauthorized transformation * Resurrection of a destroyed object * Rehydration of zeroized material * Rollback to a prior lifecycle state * Any transition that bypasses identity or lineage validation Illegal transitions MUST NOT produce descendants, MUST NOT alter lineage, and MUST NOT modify lifecycle state. Environments MUST treat illegal transitions as terminal failures. 6.3 Terminal States Terminal states represent lifecycle conditions from which an object cannot return. Terminal states include: * Destroyed * Revoked * Expired Once an object enters a terminal state, it MUST NOT be reactivated, transformed, copied, or used. Terminal states ensure that object security terminates predictably and irreversibly when required. 6.4 Zeroization Physics Zeroization is the irreversible removal of sensitive material from an SDLP object. Zeroization MUST occur during destruction and MAY occur during other terminal transitions. Zeroization MUST ensure that: * Sensitive material is irrecoverable. * The object cannot be rehydrated, resurrected, or reinstantiated. * Identity and lineage bindings cannot be reconstructed. * Cryptographic material cannot be extracted or replayed. Zeroization physics guarantees that destruction is final and that object security cannot be restored or duplicated after termination. 7. Lineage Physics SDLP Physics defines the laws governing lineage behavior for all SDLP objects. Lineage represents the complete, immutable history of an object’s transitions from its root identity through all descendants. Lineage MUST remain stable, append-only, and cryptographically verifiable across all compliant environments. Lineage physics ensures that descendant objects reflect legitimate, validated transitions and that object security depletes or transforms predictably as the object is activated, used, or shared. Lineage MUST NOT be rewritten, truncated, replaced, or bypassed. All lifecycle transitions MUST validate lineage before proceeding. 7.1 Immutable Ancestry SDLP lineage MUST be immutable. Once a lineage entry is created, it MUST NOT be modified, removed, or replaced. Immutable ancestry ensures that an object’s complete history remains verifiable and that no environment can conceal, alter, or rewrite past transitions. Immutable ancestry also ensures that identity stability and lifecycle determinism remain enforceable across all environments and distribution paths. 7.2 Descendant Rules Descendant objects MUST inherit the complete lineage of their parent and MUST append a new lineage entry reflecting the transition that produced them. Descendants MUST receive new identities that bind to the updated lineage and lifecycle state. Descendants MUST NOT be produced through illegal transitions, including unauthorized activation, unauthorized copying, resurrection, rollback, or rehydration. Environments MUST reject any transition that attempts to produce a descendant without valid lineage inheritance. 7.3 Transformation Physics Transformations MUST produce legitimate descendants whose lineage reflects the transformation event. Transformation physics ensures that object behavior remains deterministic and that lineage accurately represents the object’s evolution. Transformations MUST: * Preserve identity stability. * Append a new lineage entry. * Update lifecycle state deterministically. * Bind the new identity to the updated lineage and environment. Transformations MUST NOT bypass lineage validation or produce descendants that conceal or omit prior transitions. 7.4 Copying Physics Copying behavior is governed by object class and MUST conform to SDLP Physics. Copying MUST produce one of the following outcomes: * For identity-bound objects: Copying MUST NOT produce a functional duplicate. The copied bytes MUST NOT yield a valid identity, and the resulting object MUST NOT be usable, activatable, or transformable. * For copy-permitted objects: Copying MUST produce a legitimate descendant with a new identity and an appended lineage entry reflecting the copy transition. Copying MUST NOT reset object security, bypass lineage, or produce multiple objects with identical identities. Copying physics ensures that object security depletes or transforms predictably as objects are shared or duplicated. 8. Environment Physics SDLP Physics defines the laws governing how environments validate, execute, and enforce SDLP object behavior. Environments provide the signals required to confirm identity stability, lineage integrity, lifecycle state, and transition legality. Environment physics ensures that object security depletes, transforms, or terminates predictably as the object is activated, used, or shared. Environments MUST enforce SDLP invariants and MUST reject any object or transition that violates identity, lineage, lifecycle, or cryptographic requirements. Environment physics ensures that SDLP objects behave consistently across all compliant implementations, regardless of platform, distribution path, or execution context. 8.1 Trusted Execution Signals Environments MUST provide trusted, verifiable signals required to validate SDLP object behavior. These signals include: * Identity validation signals * Lineage verification signals * Lifecycle state verification signals * Time and monotonicity signals * Cryptographic verification signals Trusted execution signals MUST be resistant to tampering, replay, rollback, and forgery. Environments MUST NOT permit transitions when trusted signals are missing, invalid, or unverifiable. 8.2 Validation Physics Before permitting any lifecycle transition, environments MUST validate: * Identity stability * Lineage integrity * Lifecycle state consistency * Environment binding * Cryptographic signatures and hashes * Transition legality Validation MUST be deterministic and MUST produce identical results across all compliant environments. If validation fails, the transition MUST be rejected and MUST NOT produce descendants or modify object state. 8.3 Rejection Physics Environments MUST reject objects and transitions that violate SDLP Physics. Rejection MUST occur when: * Identity is invalid, duplicated, or unverifiable. * Lineage is incomplete, truncated, rewritten, or inconsistent. * Lifecycle state is illegal or inconsistent. * Transition type is unauthorized or illegal. * Cryptographic material fails verification. * Time signals are inconsistent or non-monotonic. * Environment binding cannot be confirmed. Rejection MUST be deterministic and MUST NOT permit partial or incomplete transitions. Rejected transitions MUST NOT produce descendants or alter lineage. 8.4 Time Physics Environments MUST provide time signals that are: * Monotonic * Tamper-evident * Consistent across transitions * Resistant to rollback and replay Time physics ensures that lifecycle transitions occur in a predictable order and that lineage entries reflect accurate temporal progression. Non-monotonic or manipulated time signals MUST cause transitions to be rejected. Time physics prevents resurrection, rollback, rehydration, and other illegal transitions that depend on manipulating temporal state. 9. Cryptographic Physics SDLP Physics defines the cryptographic laws governing identity, lineage, lifecycle, and environment validation. Cryptographic operations MUST be deterministic, verifiable, and resistant to tampering, replay, rollback, and forgery. Cryptographic physics ensures that object security depletes, transforms, or terminates predictably as the object is activated, used, or shared. All cryptographic material associated with an SDLP object MUST bind to identity, lineage, lifecycle state, and environment signals. Binding MUST be stable, irreversible when required, and verifiable across all compliant environments. 9.1 Deterministic Hashing Hash operations performed on SDLP objects MUST be deterministic. Identical inputs MUST produce identical outputs across all compliant environments. Hash determinism is required for: * Identity stability * Lineage integrity * Transition validation * Tamper detection * Environment binding Hashes MUST NOT depend on non-deterministic inputs such as local randomness, environment-specific metadata, or non-canonical encoding. 9.2 Deterministic Signatures Digital signatures applied to SDLP objects MUST be deterministic and verifiable across all compliant environments. Signature physics ensures that identity, lineage, and lifecycle state are bound consistently and cannot be forged or replayed. Signature verification MUST fail when: * Identity is duplicated or unverifiable. * Lineage is incomplete or inconsistent. * Lifecycle state is illegal or non-monotonic. * Environment signals are missing or invalid. 9.3 Binding Physics Cryptographic material MUST bind to: * Identity * Lineage * Lifecycle state * Environment signals * Time physics Binding MUST be stable and MUST NOT permit re-binding to alternate identities, lineage roots, or lifecycle states. Binding physics ensures that object security cannot be reset, duplicated, or bypassed through manipulation of cryptographic material. 9.4 Cryptographic Determinism All cryptographic operations MUST be deterministic. Deterministic cryptography ensures that: * Transitions produce predictable results. * Lineage updates remain consistent. * Identity validation behaves uniformly across environments. * Illegal transitions cannot exploit cryptographic variability. Non-deterministic cryptographic behavior MUST cause transitions to be rejected. 9.5 Cryptographic Zeroization Cryptographic zeroization is the irreversible destruction of cryptographic material associated with an SDLP object. Zeroization MUST ensure that: * Sensitive material is irrecoverable. * Identity and lineage bindings cannot be reconstructed. * Signatures and hashes cannot be replayed or revalidated. * The object cannot be resurrected, rehydrated, or reinstantiated. Cryptographic zeroization MUST occur during destruction and MAY occur during other terminal transitions. Zeroization physics guarantees that cryptographic termination is final and that object security cannot be restored after termination. 10. Destruction Physics SDLP Physics defines the laws governing destruction behavior for all SDLP objects. Destruction represents the irreversible termination of an object’s lifecycle, identity, lineage, and cryptographic material. Destruction MUST be final, MUST be deterministic, and MUST prevent any form of resurrection, rollback, or rehydration. Destruction physics ensures that object security terminates in a predictable and verifiable manner. Once destruction occurs, the object MUST NOT be activated, transformed, copied, or used. All environments MUST enforce destruction physics uniformly and MUST reject any attempt to interact with a destroyed object. 10.1 Irreversible Termination Destruction MUST irreversibly terminate the object’s lifecycle. After destruction: * The object MUST enter a terminal state. * The object MUST NOT transition to any other lifecycle state. * The object MUST NOT produce descendants. * The object MUST NOT be reactivated or reused. Irreversible termination ensures that object security cannot be reset, bypassed, or restored through manipulation of state or environment. 10.2 Destruction Preconditions Before destruction may occur, environments MUST validate: * Identity stability * Lineage integrity * Lifecycle state consistency * Environment binding * Cryptographic signatures and hashes If validation fails, destruction MUST NOT proceed. Destruction MUST only occur when the object is in a valid, consistent state. 10.3 Lineage Finalization Destruction MUST append a final lineage entry reflecting the destruction event. This entry MUST: * Identify the destruction transition. * Bind to the object’s final lifecycle state. * Bind to environment and time signals. * Be immutable and verifiable across all environments. Lineage finalization ensures that destruction is recorded as part of the object’s permanent history and that no environment can conceal or rewrite the termination event. 10.4 Zeroization Requirements Destruction MUST perform zeroization of sensitive material. Zeroization MUST ensure that: * Cryptographic material is irrecoverable. * Identity and lineage bindings cannot be reconstructed. * Signatures and hashes cannot be replayed. * The object cannot be resurrected, rehydrated, or reinstantiated. Zeroization MUST be deterministic and MUST produce identical results across all compliant environments. 10.5 Post-Destruction Behavior After destruction: * The object MUST NOT respond to activation attempts. * The object MUST NOT validate identity or lineage. * The object MUST NOT permit copying or transformation. * The object MUST NOT produce descendants. * The object MUST NOT accept environment signals. Environments MUST treat destroyed objects as inert and MUST reject any transition or operation involving them. 10.6 Resurrection Prohibition Resurrection of a destroyed object is strictly prohibited. Environments MUST reject any attempt to: * Rehydrate zeroized material. * Restore prior lifecycle states. * Replay lineage entries. * Reconstruct identity or cryptographic bindings. Resurrection prohibition ensures that destruction is final and that object security cannot be restored or duplicated after termination. 11. Security Considerations SDLP Physics defines the foundational security properties that govern identity, lineage, lifecycle, environment validation, and destruction. These properties ensure that SDLP objects behave predictably and securely across all compliant environments. Security considerations describe the threats addressed by SDLP Physics and the requirements environments MUST enforce to maintain object security. 11.1 Threat Model SDLP Physics is designed to mitigate the following classes of threats: * Identity duplication or forgery * Lineage rewriting, truncation, or concealment * Unauthorized activation or transformation * Unauthorized copying or replication * Resurrection or rollback of destroyed objects * Rehydration of zeroized material * Manipulation of environment signals * Cryptographic replay or forgery * Temporal manipulation or non-monotonic time behavior SDLP Physics ensures that object security depletes, transforms, or terminates predictably as the object is activated, used, or shared. 11.2 Enforcement Requirements Environments MUST enforce all SDLP invariants and MUST reject any transition or operation that violates identity, lineage, lifecycle, environment, or cryptographic physics. Enforcement requirements include: * Validating identity stability * Verifying lineage integrity * Confirming lifecycle state consistency * Ensuring environment binding * Enforcing deterministic transitions * Rejecting illegal transitions * Maintaining monotonic time signals * Performing irreversible zeroization during destruction Failure to enforce these requirements compromises SDLP object security and MUST be treated as a critical implementation error. 11.3 Illegal Transition Handling Illegal transitions—including unauthorized activation, unauthorized copying, resurrection, rollback, and rehydration—MUST be rejected deterministically. Illegal transitions MUST NOT: * Modify object state * Produce descendants * Alter lineage * Update lifecycle state * Consume or reset object security Environments MUST treat illegal transitions as terminal failures. 11.4 Replay and Forgery Resistance SDLP Physics requires deterministic cryptographic operations to prevent replay and forgery. Environments MUST reject: * Replayed signatures * Replayed lineage entries * Replayed environment signals * Replayed time signals * Replayed lifecycle states Replay resistance ensures that object security cannot be bypassed through duplication or temporal manipulation. 11.5 Destruction and Zeroization Security Destruction MUST be irreversible. Zeroization MUST ensure that: * Sensitive material cannot be recovered * Identity cannot be reconstructed * Lineage cannot be replayed * Cryptographic bindings cannot be restored * The object cannot be resurrected or rehydrated Destruction physics ensures that termination is final and that object security cannot be restored after termination. 11.6 Environment Trust and Isolation Environments MUST provide trusted execution signals and MUST isolate SDLP object processing from untrusted components. Environments MUST prevent: * Tampering with validation signals * Manipulation of time physics * Interference with lineage updates * Unauthorized access to cryptographic material Environment trust ensures that SDLP Physics remains enforceable across all compliant implementations. 11.7 Interoperability Considerations All compliant environments MUST enforce SDLP Physics uniformly. If an environment fails to enforce physics, objects processed within that environment MUST be treated as untrusted. Interoperability requires: * Consistent validation behavior * Deterministic transition outcomes * Stable identity and lineage bindings * Uniform destruction and zeroization semantics Environments that do not enforce SDLP Physics MUST NOT participate in SDLP object processing. 12. IANA Considerations This document has no IANA actions. No registries are created or modified by this document, and no protocol parameters require assignment or review by IANA. 13. References 13.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. 13.2 Informative References [SDLP-ARCH] Norton, M., "Secured Digital Lifecycle Protocol (SDLP) Architecture", Work in Progress. [SDLP-ID] Norton, M., "Secured Digital Lifecycle Protocol (SDLP) Identity Specification", Work in Progress. [SDLP-LINEAGE] Norton, M., "Secured Digital Lifecycle Protocol (SDLP) Lineage Specification", Work in Progress. [SDLP-OBJ] Norton, M., "Secured Digital Lifecycle Protocol (SDLP) Object Format", Work in Progress. 14. Author’s Address M. Norton Independent Submission El Mirage, Arizona, USA Email: mark433norton@gmail.com