Internet-Draft M. Norton Intended status: Informational Independent Expires: 28 December 2026 28 June 2026 SDLP RFC 3: Transformation and Lineage Rules draft-norton-sdlp-obj-format-00 M. Norton Individual Submission 28 June 2026 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Abstract This document defines the transformation rules and lineage guarantees for the Secured Digital Lifecycle Protocol (SDLP). Transformations represent any modification, duplication, conversion, or derivative operation performed on an SDLP object. All transformations MUST produce descendant identities, extend lineage, preserve ancestry, and maintain tamper-evident integrity. This document defines the transformation model, lineage structure, invariants, and security requirements that govern all SDLP transformations, including updated lifecycle semantics introduced in this revision. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it 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. 1. Introduction Transformation is a core concept in the Secured Digital Lifecycle Protocol (SDLP). A transformation represents any operation that produces a new version, derivative, or materialization of an SDLP object. All transformations MUST produce a descendant DigitalID, extend lineage, and maintain tamper-evident integrity. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174 when, and only when, they appear in all capitals, as shown here. This revision incorporates updated lifecycle semantics introduced in SDLP RFC 2, including the Embryo, Active, Restricted, SafeMode, Hospice, Decayed, and Bit-Drop states. These lifecycle states define the conditions under which transformations may occur, the security posture of the object during transformation, and the mandatory transition rules that govern descendant creation. This document defines: * the SDLP transformation model * the rules governing descendant identity creation * lineage structure and inheritance * transformation invariants * transformation types * transformation logging requirements * security properties associated with transformations This specification builds upon SDLP RFC 1 (DigitalID Specification) and SDLP RFC 2 (Lifecycle State Machine). 2. Transformation Overview A transformation is any operation that results in a new SDLP object derived from an existing one. Transformations include, but are not limited to: * duplication * format conversion * editing or modification * extraction or embedding * export or import * derivative creation * structural or metadata changes Transformations MAY occur only when permitted by the object's current lifecycle state. Certain states (e.g., SafeMode, Hospice, Decayed) impose additional restrictions or mandatory behaviors that affect whether a transformation is allowed, deferred, or prohibited. All transformations MUST: * generate a descendant DigitalID * extend the lineage chain * produce a new canonical bitdump * apply a new seal * record the transformation event 3. Lineage Model Lineage represents the genealogical chain of an SDLP object. Each transformation extends the lineage by appending a new component. Example lineage progression: 1 1.1 1.1.1 1.2 1.2.1 1.2.1.1 Lineage MUST be: * strictly hierarchical * append-only * tamper-evident * cryptographically verifiable Each lineage component represents a single transformation event. Descendant objects inherit the full lineage of their ancestors, forming a complete genealogical chain from the original creation event to the present state. Lineage persists across all lifecycle states, including SafeMode, Restricted, Hospice, Decayed, and Bit-Drop, ensuring that ancestry remains intact even when an object transitions into terminal or destructive states. 4. Transformation Types SDLP defines several classes of transformations. Each class has distinct rules governing identity, lineage, and output structure. Transformation classes include: * Representational Transformations * Structural Transformations * Derivative Transformations * Instance-Level Transformations * Lifecycle-Driven Transformations Representational transformations modify the encoding or format of an object without altering its semantic content. Structural transformations modify the internal organization or composition of an object. Derivative transformations produce new objects whose content is derived from, but not identical to, the parent. Instance-level transformations operate on materializations of an object rather than the object itself. Lifecycle-driven transformations correspond to state transitions defined in SDLP RFC 2, including transitions into SafeMode, Hospice, Decayed, and Bit-Drop when triggered by policy, tamper events, or end-of-life conditions. 5. Transformation Invariants All SDLP transformations MUST satisfy the following invariants: * I1. Deterministic Output -- Given identical inputs, a transformation MUST produce identical outputs. * I2. Lineage Preservation -- A transformation MUST append a lineage entry and MUST NOT remove or alter existing lineage. * I3. Identity Rules -- A transformation MUST follow the identity rules defined in SDLP RFC 1 when determining whether a new DigitalID is created. * I4. Canonical Bitdump -- Every transformation MUST produce a new canonical bitdump representing the transformed object. * I5. Sealing Requirement -- Every transformation MUST apply a new seal binding the output to its lineage entry. These invariants ensure that SDLP transformations remain predictable, verifiable, and tamper-evident across all implementations. They apply uniformly across all lifecycle states except Bit-Drop, which represents irreversible terminal destruction and therefore does not produce further transformations or lineage extensions. 6. Transformation Logging Requirements Every transformation MUST generate a transformation log entry. This entry binds the transformation event to the resulting object and provides the information necessary to verify lineage, identity, and integrity. A transformation log entry MUST include: * the parent DigitalID * the parent InstanceID (if applicable) * the transformation type * the timestamp of the transformation * the actor identity * the canonical bitdump hash of the output * the seal applied to the output * the resulting DigitalID * the resulting InstanceID (if applicable) Transformation logs MUST be: * append-only * cryptographically verifiable * bound to the output seal * immutable once recorded Implementations MAY store transformation logs locally, remotely, or in distributed systems, but the log format and verification semantics MUST remain consistent across all implementations. Logs MUST remain available for verification throughout the object's lifecycle, including during SafeMode, Restricted, Hospice, and Decayed states. Bit-Drop represents terminal destruction and therefore does not generate additional log entries. 7. Security Considerations Transformations introduce several security risks that SDLP MUST mitigate. These include: * unauthorized transformations * lineage forgery * identity spoofing * tampering with transformation logs * replaying old transformations * producing malformed or ambiguous outputs All transformations MUST be authenticated and authorized. Actors MUST be uniquely identifiable. Transformation logs MUST be sealed and cryptographically bound to both the input and output objects. Lineage verification MUST detect: * missing lineage entries * altered lineage entries * invalid transformation types * mismatched seals * broken ancestry chains Implementations MUST reject any object whose lineage cannot be fully validated. Objects entering SafeMode due to integrity failures MUST undergo full lineage verification before any further transformations are permitted. Objects in Hospice or Decayed states MUST NOT undergo additional transformations except the mandatory transition to Bit-Drop. 8. IANA Considerations This document makes no requests of IANA. Appendix A. Transformation Examples A.1. Format Conversion A PDF converted to EPUB produces a new DigitalID. The lineage entry records the parent object, the conversion type, and the resulting canonical bitdump. A.2. Duplication A duplication event produces a new InstanceID but does not create a new DigitalID. The lineage entry records a COPY transformation. A.3. Packaging Packaging multiple objects into a container produces a new parent object whose lineage entry lists all child DigitalIDs. A.4. Derivative Creation A derivative work (e.g., edited audio, cropped image, excerpted text) produces a new DigitalID. The lineage entry MUST specify the derivative transformation type. Author's Address M. Norton Email: mark433norton@gmail.com