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