Internet-Draft M. Norton Intended status: Informational Independent Expires: January 2, 2027 July 2, 2026 SDLP RFC 1: DigitalID Specification draft-norton-sdlp-identity-01 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com July 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 DigitalID specification for the Secured Digital Lifecycle Protocol (SDLP). The DigitalID is the foundational identity construct for all SDLP-governed objects, providing deterministic uniqueness, lineage preservation, collision elimination, and stable identity bindings across all compliant implementations. This document updates and formalizes the DigitalID structure, canonical encoding rules, lineage grammar, identity assignment requirements, collision model, and validation rules originally introduced in draft-norton-sdlp-identity-00. 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-governed object MUST possess a DigitalID that uniquely identifies the object, encodes its origin, preserves its lineage, and provides a stable identity binding across all compliant implementations. The DigitalID is independent of lifecycle mechanics, lineage verification, and security enforcement; it serves exclusively as the canonical identity layer for SDLP. This document defines the authoritative SDLP Identity Model. It specifies the DigitalID structure, canonical encoding rules, lineage grammar, identity assignment requirements, collision model, identity stability guarantees, and validation rules. This document updates and replaces the initial identity definition introduced in draft- norton-sdlp-identity-00. The DigitalID is a structured, hierarchical identifier composed of the following components in strict canonical order: DistributorID.CustomerID.ProductID.ProductName.DownloadID. Lineage.Timestamp ProductName appears immediately after ProductID and before DownloadID. This ensures that objects with identical ProductIDs but different product variants, editions, or SKUs remain uniquely identifiable. This ordering is mandatory and MUST be preserved across all SDLP implementations. The SDLP Identity Model defines identity only. It does not define lifecycle transitions, lineage verification, cryptographic sealing, BitDrop destruction semantics, or any other SDLP physics. Those behaviors are defined in companion SDLP specifications. The DigitalID remains stable, canonical, and immutable regardless of the object's lifecycle state or security posture. 2. Design Goals The DigitalID is designed to satisfy the following goals: * Deterministic uniqueness: no two SDLP objects may share the same DigitalID under correct operation. * Lineage preservation: all descendant objects MUST encode their ancestry through a canonical lineage grammar. * Collision elimination: identity collisions MUST be structurally impossible when DigitalIDs are assigned according to this specification. * Canonical representation: all DigitalIDs MUST be encoded and compared in a byte-exact manner without normalization or transformation. * Identity stability: once assigned, a DigitalID MUST remain immutable for the lifetime of the object. * Protocol independence: the DigitalID MUST remain valid across all transports, storage systems, and SDLP-compliant implementations. * Structural clarity: the DigitalID MUST provide a predictable and strictly ordered hierarchy of identity components, including ProductName positioned after ProductID and before DownloadID. 3. DigitalID Structure A DigitalID is a structured, hierarchical identifier composed of the following components in strict canonical order: DistributorID.CustomerID.ProductID.ProductName.DownloadID. Lineage.Timestamp Each component is defined as follows: * DistributorID: the entity that originates or distributes the digital good. This value identifies the upstream source of the object and MUST remain stable across all descendant identities. * CustomerID: the entity receiving, activating, or otherwise acquiring the digital good. CustomerID binds the identity to the initial acquisition context. * ProductID: the unique identifier of the product. ProductID distinguishes the product family or base item. * ProductName: the human-readable product variant, edition, or SKU. ProductName MUST appear immediately after ProductID and before DownloadID. This ordering ensures that objects with the same ProductID but different variants remain uniquely identifiable. * DownloadID: the unique identifier of the acquisition event. DownloadID MUST be unique per acquisition and MUST NOT be reused across objects. * Lineage: a dot-separated sequence representing ancestry. Lineage MUST follow the canonical lineage grammar defined in Section 4. * Timestamp: the creation or transformation time in canonical form. Timestamp MUST be stable, precise, and comparable across implementations. The DigitalID MUST be treated as a single, canonical UTF-8 string. No whitespace, padding, alternate separators, or normalization rules are permitted. The component ordering defined above is mandatory and MUST NOT be altered. 3.1 Canonical Form A DigitalID MUST be represented as a single, canonical UTF-8 string using dot separators between components. No whitespace, padding, alternate separators, or normalization rules are permitted. Implementations MUST preserve the exact byte sequence of the DigitalID. Case folding, Unicode normalization, trimming, or any transformation that alters the canonical byte representation is prohibited. The canonical form defined in this section is mandatory and MUST be used for storage, transmission, comparison, and validation. 3.2 Comparison Rules Two DigitalIDs are equal if and only if their canonical UTF-8 byte sequences match exactly. Implementations MUST compare DigitalIDs using strict byte-for-byte equality without applying any form of normalization or transformation. Case folding, Unicode normalization, whitespace trimming, or any modification that alters the canonical byte sequence is prohibited. DigitalIDs MUST NOT be interpreted using locale-specific rules or comparison semantics. Implementations MUST treat the DigitalID as an opaque identifier. No component-level interpretation, reordering, or partial matching is permitted during comparison. 4. Identity Assignment Identity assignment defines how a DigitalID is created, extended, and preserved across the lifetime of an SDLP-governed object. All identity assignment operations MUST follow the rules in this section. 4.1 Origin Identity When an SDLP object is first created, the Identity Authority (IA) assigns the following components: * DistributorID * CustomerID * ProductID * ProductName * DownloadID * Lineage = "1" * Timestamp These values form the root DigitalID of the object. The root identity MUST remain immutable for the lifetime of the object and MUST NOT be regenerated, replaced, or rewritten. 4.2 Descendant Identity Any duplication, transformation, export, or materialization event MUST produce a descendant DigitalID. Descendant identities extend the lineage component while preserving all other components of the root identity. The lineage component MUST be extended according to the canonical lineage grammar defined in Section 4.3. Each descendant MUST have a unique lineage value that reflects its position in the ancestry chain. 4.3 Lineage Grammar Lineage is a dot-separated sequence of positive integers. The first object in any lineage chain MUST use the value "1". Each descendant MUST append a new integer to the end of the lineage sequence. Examples: * First child of the root: 1.1 * Second child of the root: 1.2 * First child of 1.2: 1.2.1 Lineage values MUST NOT be reused, reordered, truncated, or replaced. Lineage MUST grow monotonically and MUST reflect the exact ancestry of the object. 4.4 Identity Preservation All components of the DigitalID except lineage and timestamp MUST remain identical across all descendants. DistributorID, CustomerID, ProductID, ProductName, and DownloadID MUST NOT change once the root identity has been assigned. Descendant identities MUST preserve the full ancestry chain and MUST NOT remove or alter any lineage segments. 5. Collision Model The DigitalID structure is designed to eliminate identity collisions through deterministic component ordering, unique acquisition values, and canonical lineage extension. This section defines the collision model for SDLP-governed objects. 5.1 Collision Prevention Because DigitalIDs encode DistributorID, CustomerID, ProductID, ProductName, DownloadID, lineage, and timestamp, it is structurally impossible for two independently created objects to share the same DigitalID. Each component contributes to deterministic uniqueness. Implementations MUST ensure that DownloadID values are unique per acquisition event. Lineage values MUST be unique per descendant. Timestamp values MUST reflect the actual creation or transformation time of the object. 5.2 Collision Absorption If an implementation attempts to create an object with an existing DigitalID, the event MUST be treated as a duplication. The system MUST generate a descendant DigitalID, extend the lineage component, and preserve all other components of the original identity. Collision absorption ensures that identity conflicts do not result in overwriting or replacing existing objects. Instead, the lineage chain grows to reflect the duplication event. 5.3 Collision Resolution Under correct operation, collisions cannot occur. The only possible collision scenario arises from incorrect identity assignment or unauthorized modification of the DigitalID. In such cases, the implementation MUST reject the conflicting identity, treat the DigitalID as invalid, and require regeneration of a correct descendant identity. No system MAY accept two objects with identical DigitalIDs. 6. Security Properties The DigitalID provides several security-relevant properties that support the broader SDLP architecture. These properties apply to identity only and do not define lifecycle or destruction behavior. 6.1 Immutability Once assigned, a DigitalID MUST remain immutable for the lifetime of the object. No component other than lineage and timestamp may be altered. Immutability ensures that identity cannot be rewritten or forged after creation. 6.2 Non-Repudiation Because the DigitalID encodes DistributorID, CustomerID, ProductID, ProductName, and DownloadID, the origin and acquisition context of an object cannot be repudiated. Implementations MUST preserve these values exactly as assigned. 6.3 Lineage Integrity The lineage component provides a tamper-evident record of ancestry. Any unauthorized modification of lineage MUST be detectable through comparison with expected canonical values. Lineage integrity ensures that ancestry cannot be concealed or falsified. 6.4 Structural Resistance The strict component ordering and canonical encoding rules prevent structural attacks that rely on normalization, alternate separators, or ambiguous parsing. Implementations MUST treat the DigitalID as an opaque, byte-exact identifier to avoid such vulnerabilities. 6.5 Identity Isolation The DigitalID is independent of lifecycle state, security posture, and environmental conditions. Identity remains valid and stable regardless of how the object is stored, transmitted, duplicated, or transformed. This isolation ensures that identity cannot be altered through indirect means. 7. Validation Rules Implementations MUST validate every DigitalID before accepting, storing, or processing it. Validation ensures that the identifier conforms to the structure, ordering, and canonical encoding rules defined in this specification. 7.1 Structural Validation A DigitalID MUST contain all required components in the exact canonical order: DistributorID.CustomerID.ProductID.ProductName.DownloadID. Lineage.Timestamp Missing components, reordered components, or additional components render the DigitalID invalid. Implementations MUST reject any identifier that does not match this structure. 7.2 Component Validation Each component MUST conform to its defined syntax: * DistributorID: non-empty UTF-8 string without separators. * CustomerID: non-empty UTF-8 string without separators. * ProductID: non-empty UTF-8 string without separators. * ProductName: non-empty UTF-8 string without separators. * DownloadID: unique per acquisition event. * Lineage: dot-separated positive integers. * Timestamp: canonical SDLP timestamp format. Components MUST NOT contain whitespace, alternate separators, or characters that would alter canonical parsing. 7.3 Canonical Encoding Validation The DigitalID MUST be encoded as a single UTF-8 string using dot separators. Implementations MUST verify that the identifier has not been normalized, case-folded, trimmed, or transformed. Any deviation from the canonical byte sequence MUST cause the DigitalID to be rejected. 7.4 Lineage Validation The lineage component MUST follow the canonical lineage grammar. Each segment MUST be a positive integer. The first segment MUST be "1". Descendant identities MUST append exactly one new segment. Lineage values MUST NOT be reused, reordered, truncated, or replaced. Any violation renders the DigitalID invalid. 7.5 Timestamp Validation The timestamp MUST conform to the canonical SDLP timestamp format. Implementations MUST verify that the timestamp is well-formed, comparable, and consistent with the object's creation or transformation event. 7.6 Rejection Requirements If any validation step fails, the DigitalID MUST be rejected. No implementation MAY accept an identifier that violates structural, component, canonical, lineage, or timestamp rules. Rejected identities MUST NOT be repaired, rewritten, or partially accepted. A new, correct DigitalID MUST be generated instead. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5234] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [ISO8601] International Organization for Standardization, "ISO 8601:2004 - Data elements and interchange formats - Information interchange - Representation of dates and times" Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com