SDLP RFC 3: Transformation and Lineage Rules
draft-norton-sdlp-obj-format-00

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