SDLP RFC 3: Lineage Specification
draft-norton-sdlp-lineage-00

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: January 2, 2027                                    July 2, 2026

                 SDLP RFC 3: Lineage Specification
                   draft-norton-sdlp-lineage-00

M. Norton
Independent
El Mirage, Arizona, USA
Email: mark433norton@gmail.com
July 2026

Abstract

   This document defines the SDLP lineage model, which provides a
   canonical method for representing the ancestry of SDLP-governed
   objects. Lineage is a structural property that records how an object
   evolves through duplication and transformation events. The lineage
   model ensures that descendant objects remain uniquely identifiable
   and traceable across all lifecycle transitions. This specification
   defines the lineage grammar, extension rules, validation
   requirements, and interactions with the SDLP lifecycle model.

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.

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

1.  Introduction

   The SDLP lineage model defines how SDLP-governed objects record and
   represent their ancestry. Lineage is a structural property that
   captures the sequence of duplication and transformation events that
   produce descendant objects. Each descendant extends the lineage of
   its parent, forming a canonical chain that reflects the object's
   evolution over time.

   Lineage is essential for maintaining continuity across SDLP
   lifecycle transitions. While the SDLP identity model ensures that
   objects remain uniquely identifiable, lineage provides the historical
   context needed to understand how an object came to exist in its
   current form. Together, identity and lineage allow SDLP systems to
   track object provenance, enforce security policies, and validate
   object integrity.

   This document defines the SDLP lineage grammar, extension rules,
   validation requirements, and interactions with the SDLP lifecycle
   model. It is intended to serve as the normative reference for all
   SDLP components that rely on lineage semantics.

2.  Lineage Overview

   The SDLP lineage model provides a canonical representation of the
   ancestry of SDLP-governed objects. Lineage expresses how an object
   evolves through duplication and transformation events, forming a
   structured chain that reflects the object's historical development.
   Each element in the lineage chain corresponds to a specific event
   that produced a descendant object.

   Lineage is distinct from identity. Identity defines the stable
   attributes that uniquely identify an object, while lineage records
   the sequence of events that led to the object's current state. An
   object retains its identity across all lifecycle transitions, but
   its lineage may extend when duplication or transformation occurs.

   The lineage model ensures that SDLP systems can determine whether an
   object is an original instance or a descendant, and whether two
   objects share a common ancestor. This capability supports provenance
   tracking, integrity validation, and security enforcement across
   distributed environments.

   The SDLP lifecycle model defines when lineage MUST extend. Duplication
   and transformation events produce new descendants, while transmission
   and materialization events do not alter lineage. This document
   specifies the grammar, rules, and validation requirements that govern
   lineage construction and interpretation.

3.  Lineage Grammar

   The SDLP lineage grammar defines the canonical structure used to
   represent the ancestry of SDLP-governed objects. Lineage is expressed
   as a dot-separated sequence of positive integers. Each integer in the
   sequence corresponds to a specific duplication or transformation
   event that produced a descendant object.

   The lineage grammar is defined as follows:

      lineage      = element *( "." element )
      element      = 1*DIGIT
      DIGIT        = %x30-39

   A lineage value MUST contain at least one element. The first element
   identifies the original instance of the object. Each subsequent
   element represents a descendant produced by a lineage-extending
   event.

   Lineage values MUST conform to the following rules:

   *  Elements MUST be positive integers without leading zeros.

   *  The sequence MUST reflect the order in which descendant objects
      were produced.

   *  The lineage MUST NOT be rewritten, truncated, or reordered.

   *  The lineage MUST extend only when required by the SDLP lifecycle
      model.

   These rules ensure that lineage values remain canonical, predictable,
   and interpretable across all SDLP implementations.

4.  Lineage Semantics

   Lineage describes the ancestry of an SDLP-governed object. Each
   element in the lineage sequence corresponds to a specific event that
   produced a descendant object. The semantics of lineage define how
   lineage values are interpreted, how they relate to object identity,
   and how they evolve across SDLP lifecycle transitions.

   A lineage value represents a complete and ordered history of the
   object's creation. The first element identifies the original
   instance. Each subsequent element reflects a duplication or
   transformation event that produced a new descendant. Lineage does not
   record transmission or materialization events, as these do not create
   new descendants.

   Lineage is a structural property. It does not describe the content,
   purpose, or behavior of the object. Instead, it provides the
   historical context necessary to understand how the object came to
   exist in its current form. Two objects with identical identity values
   but different lineage values represent distinct descendants of a
   common ancestor.

   Lineage values are immutable once assigned. An SDLP-governed object
   MUST NOT alter its lineage except when required by the SDLP lifecycle
   model. Rewriting, truncating, or reordering lineage elements is
   prohibited. These constraints ensure that lineage remains a reliable
   indicator of object provenance and supports consistent interpretation
   across distributed systems.

5.  Lineage Extension Rules

   Lineage extension occurs when an SDLP-governed object undergoes a
   lifecycle transition that produces a new descendant. The SDLP
   lifecycle model defines two events that extend lineage: duplication
   and transformation. Transmission and materialization events do not
   create descendants and therefore do not modify lineage.

   When a lineage-extending event occurs, the descendant object MUST
   append a new positive integer to the end of its parent's lineage
   value. The appended integer identifies the specific event that
   produced the descendant. The resulting lineage value reflects the
   complete ancestry of the object.

   The following rules govern lineage extension:

   *  Duplication events produce a new descendant. The descendant MUST
      extend the parent's lineage by appending a new integer.

   *  Transformation events produce a new descendant. The descendant
      MUST extend the parent's lineage by appending a new integer.

   *  Transmission events do not produce descendants. The lineage MUST
      NOT change.

   *  Materialization events do not produce descendants. The lineage
      MUST NOT change.

   *  The appended integer MUST be a positive integer without leading
      zeros.

   *  The lineage sequence MUST preserve the order in which descendants
      were produced.

   *  Implementations MUST NOT rewrite, truncate, or reorder lineage
      values.

   These rules ensure that lineage remains a reliable indicator of
   object provenance and that all SDLP implementations interpret lineage
   extension consistently.

6.  Validation Rules

   SDLP implementations MUST validate lineage values to ensure that they
   conform to the canonical grammar and semantics defined in this
   specification. Validation is required whenever an SDLP-governed
   object is created, received, processed, or stored.

   A lineage value is considered valid only if it meets all of the
   following requirements:

   *  The lineage MUST consist of one or more dot-separated positive
      integers.

   *  Each element MUST contain only ASCII digits and MUST NOT include
      leading zeros.

   *  The lineage MUST reflect a complete and ordered sequence of
      lineage-extending events.

   *  The lineage MUST NOT be rewritten, truncated, reordered, or
      otherwise modified except when required by the SDLP lifecycle
      model.

   *  The lineage MUST extend only when duplication or transformation
      events occur. Implementations MUST reject lineage extensions
      associated with transmission or materialization events.

   *  The lineage MUST NOT contain empty elements, malformed elements,
      or non-numeric characters.

   *  The lineage MUST NOT contain negative integers or zero-valued
      elements.

   Implementations SHOULD treat invalid lineage values as integrity
   failures. When an invalid lineage value is encountered, the receiving
   system SHOULD reject the object, log the failure, and apply any
   additional security policies defined by the SDLP security model.

   These validation rules ensure that lineage remains a reliable and
   interpretable indicator of object provenance across all SDLP
   deployments.

7.  Security Considerations

   Lineage is a structural property that contributes directly to the
   security posture of SDLP-governed objects. Because lineage records
   the ancestry of an object, it plays a critical role in provenance
   tracking, integrity validation, and the enforcement of SDLP security
   policies. Implementations MUST ensure that lineage values are
   protected from unauthorized modification.

   Lineage falsification is a primary threat. An attacker may attempt to
   rewrite, truncate, reorder, or otherwise alter a lineage value to
   conceal the true ancestry of an object. Such manipulation can disrupt
   provenance tracking, undermine integrity checks, and enable
   impersonation or unauthorized reuse of SDLP-governed objects.
   Implementations MUST treat any lineage modification outside of
   duplication or transformation events as an integrity failure.

   Lineage omission is also a threat. Removing elements from a lineage
   sequence can obscure the existence of intermediate descendants or
   hide unauthorized transformations. Implementations MUST reject
   lineage values that do not reflect a complete and ordered sequence of
   lineage-extending events.

   Lineage inflation, in which an attacker appends unauthorized elements
   to a lineage sequence, can misrepresent the object's history or
   create false descendant relationships. Implementations MUST validate
   all appended elements and ensure that lineage extension occurs only
   when required by the SDLP lifecycle model.

   Because lineage interacts closely with identity, attacks on lineage
   may be used to support identity spoofing or impersonation. SDLP
   systems SHOULD apply the same integrity protections to lineage that
   they apply to identity, including cryptographic verification,
   tamper-evident storage, and secure transmission mechanisms.

   These considerations ensure that lineage remains a trustworthy and
   interpretable indicator of object provenance across all SDLP
   deployments.

8.  IANA Considerations

   This document has no actions for IANA. No registries are created,
   modified, or deprecated by the SDLP lineage model. Lineage values are
   purely structural and do not require centralized allocation or
   coordination.

   Implementations MUST NOT rely on any IANA-managed namespace for the
   interpretation or validation of lineage values.

9.  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.

   [SDLP-IDENTITY]
              Norton, M., "SDLP RFC 1: Identity Specification",
              draft-norton-sdlp-identity-01, July 2026.

   [SDLP-LIFECYCLE]
              Norton, M., "SDLP RFC 2: Lifecycle Specification",
              draft-norton-sdlp-lifecycle-01, July 2026.

   [SDLP-SECARCH]
              Norton, M., "SDLP RFC 4: Security Architecture",
              draft-norton-sdlp-sec-arch-02, July 2026.

10.  Informative References

   [SDLP-OBJFORMAT]
              Norton, M., "SDLP RFC 5: Object Format Specification",
              draft-norton-sdlp-obj-format-00, July 2026.

   [SDLP-LINEAGE-EXAMPLES]
              Norton, M., "Examples of SDLP Lineage Construction",
              work in progress, 2026.

   [PROVENANCE]
              Moreau, L. and P. Groth, "Provenance: An Introduction to
              PROV", Synthesis Lectures on the Semantic Web, 2013.

   [DATA-LIFECYCLE]
              Spiekermann, S., "The Challenges of Personal Data
              Lifecycle Management", IEEE Security & Privacy, 2012.

   [TRUST-MODELS]
              Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized
              Trust Management", Proceedings of the 1996 IEEE Symposium
              on Security and Privacy, 1996.

11.  Acknowledgments

   The author thanks the participants of the IETF DISPATCH community for
   their feedback on early versions of the SDLP model. Their comments
   helped refine the structure and terminology used throughout the SDLP
   specifications.

   The author also acknowledges the contributors to the SDLP identity,
   lifecycle, and security architecture drafts. Their work established
   the foundation upon which the lineage model is built.

   Finally, the author thanks the reviewers who provided guidance on
   document formatting, clarity, and consistency across the SDLP series.

12.  Author's Address

   M. Norton
   Independent
   El Mirage, Arizona, USA
   Email: mark433norton@gmail.com