Internet-Draft M. Norton Intended status: Informational Independent Expires: November 2026 May 2026 SDLP RFC 1: DigitalID Specification draft-norton-sdlp-identity-00 M. Norton Individual Submission Email: mark433norton@gmail.com 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 DigitalID specification for the Secured Digital Lifecycle Protocol (SDLP). The DigitalID is the foundational identity construct for all SDLP objects, providing deterministic uniqueness, lineage preservation, collision elimination, and tamper-evident integrity. This document describes the DigitalID structure, assignment rules, lineage model, comparison rules, and integrity requirements. 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 The DigitalID is the foundational identity construct of the Secured Digital Lifecycle Protocol (SDLP). Every SDLP object, instance, and descendant MUST possess a DigitalID that uniquely identifies the object, encodes its origin and lineage, binds the object to its lifecycle, prevents identity collisions, and enables tamper-evident verification. This document defines the DigitalID structure, generation rules, lineage model, comparison rules, and integrity requirements. 2. Design Goals The DigitalID is designed to satisfy the following goals: * Deterministic uniqueness: no two SDLP objects may share the same DigitalID. * Lineage preservation: all descendant objects MUST encode their ancestry. * Collision elimination: identity collisions MUST be structurally impossible. * Tamper resistance: unauthorized modification MUST be detectable. * Canonical representation: all DigitalIDs MUST be comparable in a byte-exact manner. * Protocol independence: the DigitalID MUST remain valid across transports, storage systems, and implementations. 3. DigitalID Structure A DigitalID is a structured, hierarchical identifier composed of the following components: DistributorID.CustomerID.ProductID.DownloadID.Lineage.Timestamp Each component is defined as follows: * DistributorID: the entity that originates or distributes the digital good. * CustomerID: the entity receiving or activating the digital good. * ProductID: the unique identifier of the product. * DownloadID: the unique identifier of the acquisition event. * Lineage: a dot-separated sequence representing ancestry (e.g., "1", "1.2", "1.2.1"). * Timestamp: the creation or transformation time in canonical form. 3.1 Canonical Form A DigitalID MUST be represented as a UTF-8 string with dot separators. No whitespace, padding, or alternative encodings are permitted. 3.2 Comparison Rules Two DigitalIDs are equal if and only if their canonical UTF-8 byte sequences match exactly. Implementations MUST NOT perform case- insensitive comparison, Unicode normalization, or whitespace trimming. 4. Identity Assignment 4.1 Origin Identity When an SDLP object is first created, the Identity Authority (IA) assigns: * DistributorID * CustomerID * ProductID * DownloadID * Timestamp * Lineage = "1" This DigitalID becomes the root identity of the object. 4.2 Descendant Identity Any duplication, transformation, export, or materialization event MUST produce a descendant DigitalID. The lineage component is extended as follows: * First child: 1.1 * Second child: 1.2 * Child of child: 1.2.1 This ensures that no two objects ever share the same DigitalID and that all objects maintain a genealogical chain. 5. Collision Model 5.1 Collision Prevention Because DigitalIDs encode origin, acquisition event, lineage, and timestamp, it is impossible for two independently created objects to share the same DigitalID. 5.2 Collision Absorption If an implementation attempts to create an object with an existing DigitalID, the system MUST treat the event as a duplication, generate a descendant DigitalID, extend the lineage component, and preserve the original identity. 5.3 Collision Resolution Because collisions cannot occur under correct operation, the only collision scenario is tampering (see Section 7). 6. Security Properties The DigitalID MUST provide: * Immutability: once assigned, the root identity cannot change. * Lineage integrity: ancestry cannot be removed or rewritten. * Tamper evidence: unauthorized edits MUST be detectable. * Non-repudiation: the origin of an object MUST be provable. These properties are enforced through the SDLP bitdump seal. 7. Integrity and Tamper Resistance 7.1 Canonical Bitdump Every SDLP object MUST include a canonical bitdump, which is a byte- exact serialization of the DigitalID, lineage chain, lifecycle state, metadata, and payload (or its hash). This bitdump MUST be stable across implementations. 7.2 Seal A seal is a cryptographic integrity mechanism applied to the canonical bitdump. The seal MUST bind the DigitalID and lineage to the object, prevent unauthorized modification, and allow verification by any SDLP-compliant system. 7.3 Tamper Detection Any modification to DigitalID, lineage, lifecycle state, metadata, or payload that is not performed through a valid SDLP transition MUST cause seal verification to fail. 7.4 Tamper Response If a seal fails verification, the object MUST be rejected, the DigitalID MUST NOT be trusted, the lineage MUST be considered invalid, and the event MUST be logged as a security violation. 7.5 Manual Editing Manual editing of DigitalID or lineage fields is considered tampering. Because the attacker cannot recompute a valid seal without IA authorization, such edits are always detectable. 8. IANA Considerations This document makes no requests of IANA. 9. Security Considerations DigitalID tampering is always detectable. Lineage cannot be forged. Collisions cannot occur. Unauthorized identity modification is impossible without breaking the seal. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. Author's Address M. Norton El Mirage, Arizona United States Email: mark433norton@gmail.com