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.
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.
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