Internet-Draft M. Norton Intended status: Informational Independent Expires: January 27, 2027 July 27, 2026 SDLP RFC 1: DigitalID Specification draft-norton-sdlp-identity-02 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 Secured Digital Lifecycle Protocol (SDLP) defines a unified provenance, identity, and lifecycle framework for digital objects. Identity-01 introduced the initial DigitalID construct, but several inconsistencies across the SDLP suite—particularly in Lifecycle-01, Object-Format-01, and early lineage semantics—necessitated a normative revision. Identity-02 provides the authoritative definition of DigitalID, clarifies its immutability properties, removes lineage and timestamp from identity semantics, and establishes a consistent inheritance model for all SDLP-governed objects. This document supersedes Identity-01 and resolves cross-draft contradictions identified during early review and interoperability analysis. The DigitalID defined in this document is the foundational identity primitive for SDLP. All compliant implementations MUST treat the DigitalID structure and rules defined herein as normative and immutable. All other SDLP specifications—including Lifecycle, Lineage, Object Format, Physics, and Security—MUST reference this document when defining identity-related behavior. 2. Terminology The following terms are used throughout this document: DistributorID: A globally unique identifier assigned to the distributor or originator of the digital object. CustomerID: A unique identifier representing the customer, account, or recipient associated with the initial acquisition of the object. ProductID: A stable identifier for the product or title associated with the object (e.g., a movie, software title, dataset, or media asset). ProductName: A human-readable name for the product. ProductName is included in the DigitalID tuple for clarity and collision avoidance but does not affect lifecycle semantics. DownloadID: A unique identifier assigned at the moment of initial acquisition or download. DownloadID distinguishes multiple acquisitions of the same product by the same customer. Date: The calendar date on which the DigitalID was assigned. Date is immutable once set. Time: The time-of-day at which the DigitalID was assigned. Time is immutable once set. InstanceID: A per-copy identifier assigned to each object instance. InstanceID is not part of the DigitalID and may change during lifecycle transitions. Lineage: A structured record of parent-child relationships formed through lifecycle transitions. Lineage is not part of the DigitalID and may grow as objects are copied or derived. Timestamp: The Date and Time associated with a lifecycle event. Timestamp is distinct from the immutable Date and Time fields in DigitalID. DigitalID: The immutable identity tuple defined in Section 3. DigitalID uniquely identifies the origin object and is preserved across all lifecycle transitions. 3. DigitalID Definition The DigitalID is the immutable identity tuple for all SDLP objects. It uniquely identifies the origin object and remains stable across all lifecycle transitions, including copy, derivation, transformation, and multi-step lineage extension. Identity-02 is the authoritative definition of DigitalID and supersedes all identity semantics described in Identity-01. All SDLP specifications MUST treat this document as the normative source for identity structure, immutability rules, and inheritance behavior. 3.1. DigitalID Structure A DigitalID is composed of the following ordered tuple: DistributorID CustomerID ProductID ProductName DownloadID Date Time These fields collectively form the immutable identity of the object. No SDLP-compliant implementation may alter, replace, reorder, or remove any component of the DigitalID once assigned. 3.2. Immutability The DigitalID MUST remain unchanged for the entire lifecycle of the object. Descendant objects created through copy, derivation, or transformation inherit the DigitalID of their parent without modification. Lineage and InstanceID are NOT part of the DigitalID and MUST NOT be used to determine identity. These fields may change during lifecycle transitions, but DigitalID MUST NOT. 3.3. Child Object Identity A child object created through a lifecycle transition receives: * The parent DigitalID (unchanged) * A new InstanceID * An extended Lineage value * A new Date and Time corresponding to the moment of creation The combination of DigitalID + InstanceID + Lineage + Timestamp constitutes the full identity context of the child object, but only the DigitalID portion is immutable and preserved across generations. 3.4. Rationale Excluding Lineage and Timestamp from DigitalID ensures: * Identity stability across transitions * Deterministic inheritance * Collision elimination without identity mutation * Compatibility with SCITT, EMILIA, and external provenance systems * A clear separation between identity and lifecycle semantics This resolves inconsistencies present in Identity-01, Lifecycle-01, and Object-Format-01, and establishes a single authoritative identity model for all SDLP documents. 4. DigitalID Components The DigitalID is composed of seven immutable fields that collectively establish the origin identity of an SDLP-governed object. These fields are assigned at the moment of initial acquisition and MUST NOT be modified for the lifetime of the object or any of its descendants. Each component serves a distinct role in collision avoidance, provenance stability, and cross-system interoperability. The following subsections define each field and its normative requirements. 4.1. DistributorID DistributorID identifies the entity responsible for issuing or distributing the digital object. DistributorID MUST be globally unique and stable across all products and downloads issued by the distributor. Implementations MAY use UUIDs, decentralized identifiers (DIDs), or other globally unique schemes. 4.2. CustomerID CustomerID identifies the customer, account, or recipient associated with the initial acquisition of the object. CustomerID MUST be unique within the scope of the distributor and MUST remain stable across all downloads associated with the same customer. 4.3. ProductID ProductID identifies the product or title associated with the object. ProductID MUST be stable across all acquisitions of the same product and MUST NOT change based on customer, download, or instance variations. 4.4. ProductName ProductName is a human-readable label for the product. ProductName is included in the DigitalID tuple for clarity, debugging, and collision avoidance. ProductName MUST NOT be used for lifecycle or security decisions and MUST NOT affect identity semantics. 4.5. DownloadID DownloadID uniquely identifies the acquisition event that produced the origin object. DownloadID MUST be unique per acquisition and MUST NOT be reused across different downloads, even if the same customer acquires the same product multiple times. 4.6. Date Date records the calendar date on which the DigitalID was assigned. Date MUST be expressed in YYYY-MM-DD format and MUST remain immutable for the lifetime of the object and all descendants. 4.7. Time Time records the time-of-day at which the DigitalID was assigned. Time MUST be expressed in 24-hour HH:MM:SS format and MUST remain immutable for the lifetime of the object and all descendants. 4.8. Immutability Requirements All fields defined in this section collectively form the DigitalID. Implementations MUST treat the DigitalID as an atomic, immutable identity construct. None of its components may be altered, replaced, reinterpreted, or regenerated during any lifecycle transition. Descendant objects inherit the DigitalID of their parent without modification. Lineage, InstanceID, and per-transition timestamps are defined in other SDLP specifications and MUST NOT be considered part of the DigitalID. 5. DigitalID Encoding and Comparison Rules The DigitalID is an immutable identity tuple composed of seven fields defined in Section 4. To ensure interoperability across SDLP implementations, DigitalID values MUST be encoded, serialized, and compared using the rules defined in this section. Implementations MUST treat the DigitalID as an atomic identity construct. All encoding and comparison operations MUST preserve field order, field boundaries, and canonical formatting. 5.1. Canonical Encoding A DigitalID MUST be encoded as a structured tuple in the following fixed order: DistributorID CustomerID ProductID ProductName DownloadID Date Time Each field MUST be encoded using UTF-8. Implementations MUST NOT reorder fields, omit fields, or introduce additional fields. The canonical encoding format is: DistributorID "/" CustomerID "/" ProductID "/" ProductName "/" DownloadID "/" Date "T" Time For example: dist123/cust456/prod789/MovieTitle/dl001/2026-07-27T14:32:10 This encoding format is REQUIRED for all SDLP-compliant systems and MUST be used when generating signatures, hashes, or external references. 5.2. Serialization Requirements DigitalID serialization MUST meet the following requirements: * UTF-8 encoding * No whitespace padding * No optional delimiters * No locale-dependent formatting * Date MUST be YYYY-MM-DD * Time MUST be HH:MM:SS (24-hour format) Implementations MAY internally store DigitalID fields in structured form, but any external representation MUST use the canonical encoding defined above. 5.3. Comparison Rules DigitalID comparison MUST be performed using exact byte-wise equality. Implementations MUST NOT apply case folding, Unicode normalization, whitespace trimming, or locale-specific comparison rules. Two DigitalID values are considered equal if and only if: * All seven fields match exactly * Field order matches exactly * Canonical encoding matches exactly Any deviation in any field, including Date or Time, MUST be treated as a distinct DigitalID. 5.4. Collision Model The DigitalID tuple is designed to eliminate collisions through deterministic field composition. Collisions are only possible if two distinct acquisition events produce identical values for all seven fields. Implementations MUST ensure that DownloadID, Date, and Time are assigned with sufficient entropy and precision to prevent accidental collisions. Distributors SHOULD ensure that DownloadID values are globally unique within their namespace. If a collision is detected, the implementation MUST treat the objects as distinct and MUST NOT merge or reinterpret identity fields. The collision MUST be surfaced to the relying party or verifier. 5.5. Stability Across Lifecycle Transitions DigitalID MUST remain stable across all lifecycle transitions, including copy, derivation, transformation, and multi-step lineage extension. Descendant objects inherit the DigitalID of their parent without modification. Lineage, InstanceID, and per-transition timestamps are defined in other SDLP specifications and MUST NOT be included in DigitalID encoding or comparison operations. 6. DigitalID Assignment Rules The DigitalID is assigned at the moment of initial acquisition and forms the immutable identity of the origin object. This section defines the normative requirements governing DigitalID creation, assignment authority, and the conditions under which identity may be generated. 6.1. Assignment Event A DigitalID MUST be created exactly once, at the moment the origin object is produced. The assignment event occurs when: * A distributor issues a product to a customer, or * A system generates an origin object as part of a provisioning or publishing workflow. DigitalID assignment MUST precede any lifecycle transitions, including copy, derivation, transformation, or distribution to secondary systems. 6.2. Assignment Authority Only the distributor responsible for issuing the origin object MAY assign a DigitalID. The distributor MUST ensure that: * DistributorID is globally unique, * CustomerID is correctly bound to the acquisition event, * ProductID and ProductName correspond to the correct product, * DownloadID is unique within the distributor’s namespace, * Date and Time accurately reflect the assignment moment. Implementations MUST NOT permit customers, relying parties, or downstream systems to generate or modify DigitalID values. 6.3. Uniqueness Requirements A DigitalID MUST be unique for each origin object. Distributors MUST ensure uniqueness by: * Generating DownloadID values with sufficient entropy, * Recording Date and Time with second-level precision or greater, * Preventing reuse of DownloadID values across acquisitions. If a distributor cannot guarantee uniqueness, the implementation MUST treat the assignment as invalid and MUST NOT issue the object. 6.4. Assignment Constraints The following constraints apply to all DigitalID assignments: * All seven fields defined in Section 4 MUST be present. * Fields MUST be assigned in the canonical order. * Fields MUST conform to the encoding rules in Section 5. * Fields MUST NOT be altered after assignment. * Fields MUST NOT be regenerated during lifecycle transitions. Implementations MUST reject any DigitalID that omits fields, uses non-canonical formatting, or violates immutability requirements. 6.5. Assignment Failures If a DigitalID cannot be assigned due to missing information, collision detection, or distributor misconfiguration, the system MUST fail the acquisition event. The object MUST NOT be issued, stored, or transmitted until a valid DigitalID is assigned. Implementations SHOULD surface assignment failures to the relying party or verifier with sufficient diagnostic information to identify the cause. 6.6. Assignment and Lifecycle Interaction DigitalID assignment is strictly an origin event. After assignment: * Descendants inherit the DigitalID unchanged, * InstanceID is assigned per copy or derivation, * Lineage is extended per lifecycle transition, * Timestamp reflects the transition moment, not the DigitalID assignment moment. DigitalID MUST NOT be regenerated during any lifecycle transition, regardless of lineage depth, instance count, or transformation type. 7. DigitalID Validation Rules DigitalID validation ensures that identity values are well-formed, immutable, and compliant with the encoding and assignment rules defined in this document. Verifiers, relying parties, and SDLP implementations MUST apply the validation procedures described in this section before accepting any DigitalID as admissible. 7.1. Validation Preconditions A DigitalID MUST be validated prior to: * Lifecycle transition processing, * Lineage extension, * InstanceID assignment, * Signature verification, * Object admission by a relying party, * Transparency receipt generation. Implementations MUST NOT perform lifecycle or security operations on objects whose DigitalID fails validation. 7.2. Structural Validation A DigitalID is structurally valid if and only if: * All seven fields defined in Section 4 are present, * Fields appear in the canonical order, * No field is empty, * No field contains prohibited characters, * The canonical encoding format defined in Section 5 is used. Verifiers MUST reject DigitalID values that: * Omit fields, * Reorder fields, * Introduce additional fields, * Use non-canonical delimiters, * Use locale-dependent formatting. 7.3. Field-Level Validation Each DigitalID field MUST satisfy the following requirements: * DistributorID: globally unique, UTF-8, non-empty. * CustomerID: unique within distributor namespace. * ProductID: stable across all acquisitions of the same product. * ProductName: UTF-8, human-readable, non-empty. * DownloadID: unique per acquisition event. * Date: valid YYYY-MM-DD format. * Time: valid HH:MM:SS 24-hour format. Verifiers MUST reject DigitalID values containing malformed Date or Time fields, invalid UTF-8 sequences, or identifiers that violate uniqueness constraints. 7.4. Immutability Validation Verifiers MUST ensure that the DigitalID has not changed across lifecycle transitions. A DigitalID is immutable if: * The DigitalID of the child object matches the DigitalID of the parent object exactly, * No field differs between parent and child, * No field has been regenerated or replaced. If immutability is violated, the object MUST be rejected as inadmissible. 7.5. Canonical Comparison DigitalID comparison MUST use byte-wise equality of the canonical encoding defined in Section 5. Verifiers MUST NOT apply: * Case folding, * Unicode normalization, * Whitespace trimming, * Locale-specific comparison rules. Two DigitalID values are equal only if their canonical encodings are identical. 7.6. Collision Detection A collision occurs when two distinct origin objects present identical DigitalID values. Verifiers MUST detect collisions by: * Comparing canonical encodings, * Checking DownloadID uniqueness, * Checking Date and Time precision. If a collision is detected, the verifier MUST treat the objects as distinct and MUST NOT merge identity contexts. The collision MUST be surfaced to the relying party. 7.7. Validation Outcomes DigitalID validation produces one of three outcomes: * VALID: The DigitalID satisfies all structural, field-level, immutability, and encoding requirements. * INVALID: The DigitalID violates one or more validation rules. * INDETERMINATE: The verifier cannot determine validity due to missing fields, corrupted encoding, or insufficient information. INVALID DigitalID values MUST be rejected. INDETERMINATE values MAY be rejected or deferred based on verifier policy. 7.8. Error Handling When DigitalID validation fails, implementations SHOULD provide: * A clear error code, * A human-readable diagnostic message, * Identification of the failing field or rule, * Guidance for remediation when possible. Verifiers MUST NOT attempt to repair, reinterpret, or regenerate DigitalID values. Any such modification violates SDLP identity semantics and MUST be treated as a fatal error. 8. Security Considerations The DigitalID is a foundational identity construct for SDLP-governed objects. Its immutability, canonical encoding, and deterministic structure are essential for preventing identity tampering, replay attacks, and unauthorized object substitution. This section describes the security considerations associated with DigitalID generation, transmission, validation, and use. 8.1. Identity Tampering Resistance Because the DigitalID is immutable, any modification to its fields constitutes an identity tampering attempt. Implementations MUST treat any deviation from the canonical encoding or field values as a security violation. Verifiers MUST reject objects whose DigitalID: * Has been altered during transmission, * Has been regenerated during a lifecycle transition, * Contains fields inconsistent with the parent object, * Uses non-canonical formatting intended to bypass comparison. DigitalID values SHOULD be included in signed preimages or protected metadata structures to prevent unauthorized modification. 8.2. Replay Protection Replay attacks occur when an adversary reuses a previously valid DigitalID in a different context. Because DigitalID is immutable, replay protection relies on: * Verifying the binding between DigitalID and the object’s InstanceID, * Validating lineage consistency, * Ensuring timestamps correspond to legitimate lifecycle events, * Confirming that signatures or seals reference the correct DigitalID. Verifiers MUST ensure that DigitalID values are not reused across unrelated objects or lifecycle contexts. 8.3. Unauthorized Identity Substitution An adversary may attempt to substitute a valid DigitalID into a different object to bypass provenance or lifecycle controls. To mitigate this risk: * DigitalID MUST be bound to the object’s canonical representation, * DigitalID MUST be included in all lifecycle transition evidence, * Verifiers MUST confirm that DigitalID matches the object’s origin metadata. Implementations MUST NOT accept objects whose DigitalID does not correspond to the object’s canonical projection. 8.4. Collision Risks Although DigitalID is designed to eliminate collisions, poorly implemented DownloadID generation or insufficient timestamp precision may introduce collision risk. Distributors MUST ensure: * DownloadID values are generated with sufficient entropy, * Date and Time fields have second-level precision or greater, * No two origin objects receive identical DigitalID values. Verifiers MUST treat collisions as security-critical events and MUST surface them to relying parties. 8.5. Trust Boundaries DigitalID assignment occurs within the distributor’s trust boundary. Downstream systems MUST NOT generate or modify DigitalID values. Verifiers MUST assume that: * DigitalID assignment is trustworthy only if the distributor is trusted, * DigitalID values from untrusted distributors MAY be rejected, * DigitalID validation alone does not establish object authenticity. Additional trust mechanisms (e.g., signatures, seals, transparency receipts) are required to establish full provenance integrity. 8.6. Interoperability with External Systems External systems such as SCITT and EMILIA rely on DigitalID immutability and canonical encoding for interoperability. To ensure secure composition: * DigitalID MUST be included in signed preimages, * DigitalID MUST be referenced in transparency receipts, * Verifiers MUST apply the validation rules in Section 7 before accepting DigitalID as admissible. Failure to enforce these requirements may result in identity confusion, provenance loss, or unauthorized object admission. 8.7. Denial-of-Service Considerations Malformed or adversarial DigitalID values may be used to trigger excessive validation work. Implementations SHOULD: * Apply strict structural validation, * Reject malformed DigitalID values early, * Limit recursion depth for lineage validation, * Avoid expensive normalization or repair operations. DigitalID validation MUST remain deterministic and bounded in complexity. 8.8. Privacy Considerations DigitalID contains CustomerID and ProductName fields, which may be considered personal or sensitive information. Implementations SHOULD: * Protect DigitalID values during transmission, * Avoid exposing DigitalID unnecessarily, * Apply access controls when storing DigitalID values. Privacy-sensitive deployments MAY use pseudonymous CustomerID values or privacy-preserving encodings, provided canonical formatting is preserved. 9. IANA Considerations This document has no IANA actions. The DigitalID construct defined in this specification does not introduce new registries, modify existing registries, or require the allocation of protocol parameters, media types, or code points. IANA is therefore requested to take no action on this document. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [SDLP-Lifecycle] Norton, M., "SDLP RFC 2: Lifecycle Specification", draft-norton-sdlp-lifecycle-02, Work in Progress. [SDLP-ObjectFormat] Norton, M., "SDLP RFC 3: Object Format Specification", draft-norton-sdlp-object-format-02, Work in Progress. [SDLP-Lineage] Norton, M., "SDLP RFC 4: Lineage Specification", draft-norton-sdlp-lineage-01, Work in Progress. [SDLP-Security] Norton, M., "SDLP RFC 5: Security Architecture", draft-norton-sdlp-security-01, Work in Progress. [SDLP-Physics] Norton, M., "SDLP RFC 6: Physics Model", draft-norton-sdlp-physics-01, Work in Progress. 11. Informative References [SCITT-Architecture] Steele, O., et al., "SCITT Architecture", draft-ietf-scitt-architecture-13, Work in Progress. [SCITT-Receipts] Steele, O., et al., "SCITT Transparency Receipts", draft-ietf-scitt-receipts-12, Work in Progress. [EMILIA] Schrock, I., "EMILIA Protocol Overview", emiliaprotocol.ai, 2026. [C2PA] Coalition for Content Provenance and Authenticity, "C2PA Specification", Version 1.3, 2024. [W3C-DID] Sporny, M., et al., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, 2022. [UUID] Leach, P., et al., "UUIDs and GUIDs", RFC 4122, DOI 10.17487/RFC4122, July 2005. [ISO8601] International Organization for Standardization, "ISO 8601:2004 — Data elements and interchange formats — Information interchange — Representation of dates and times", 2004. Appendix A. Canonical Movie-Copy Transition Example (Informative) This appendix provides a non-normative, illustrative example of how DigitalID, InstanceID, Lineage, and Timestamp interact during a lifecycle transition. The example demonstrates the identity behavior defined in Identity-02 and the transition semantics defined in Lifecycle-02. A.1. Origin Object A customer acquires a digital movie titled "ExampleMovie" from a distributor. At the moment of acquisition, the distributor assigns the following DigitalID: DistributorID = dist123 CustomerID = cust456 ProductID = prod789 ProductName = ExampleMovie DownloadID = dl001 Date = 2026-07-27 Time = 14:32:10 Canonical encoding: dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 The origin object receives: InstanceID = 1 Lineage = 1 Timestamp = 2026-07-27T14:32:10 The DigitalID is immutable and will be inherited by all descendants. A.2. Copy Transition The customer performs a copy operation, producing a child object. Lifecycle-02 defines copy as a reproduction transition that generates a new InstanceID, extends Lineage, and assigns a new Timestamp. The child object inherits the DigitalID unchanged: dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 The child object receives: InstanceID = 1.1 Lineage = 1.1 Timestamp = 2026-07-27T15:04:22 Only InstanceID, Lineage, and Timestamp change. DigitalID remains identical to the parent. A.3. Second-Generation Copy A second copy is made from the first child object. The DigitalID is again inherited unchanged. New values assigned: InstanceID = 1.1.1 Lineage = 1.1.1 Timestamp = 2026-07-27T15:07:03 The DigitalID remains: dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10 A.4. Identity Summary Across all generations: * DigitalID remains constant. * InstanceID grows deterministically. * Lineage extends according to Lifecycle-02 grammar. * Timestamp reflects the moment of each transition. This example illustrates the core identity principle of SDLP: DigitalID is immutable and inherited by all descendants. All lifecycle transitions MUST preserve DigitalID exactly as assigned at origin. Only InstanceID, Lineage, and per-transition Timestamp may change. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com