SDLP RFC 1: DigitalID Specification
draft-norton-sdlp-identity-02

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