SDLP Object Format Specification
draft-norton-sdlp-obj-format-08

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: 06 February 2027                                 05 August 2026

                 SDLP Object Format Specification
                 draft-norton-sdlp-obj-format-08

M. Norton
Individual Submission
05 August 2026

Abstract

   This document defines the canonical object format for the Secured
   Digital Lifecycle Protocol (SDLP). The SDLP object format specifies
   the structure, encoding, and canonicalization rules for DigitalID,
   lineage fields, lifecycle timestamps, Body content, and signature
   envelopes. These rules establish the immutable semantics required for
   SDLP verification, provenance tracking, lifecycle transitions, and
   interoperability with external systems such as CAID, AEC, AEB, SCITT,
   and EMILIA.

   Version -08 updates the canonical timestamp grammar, clarifies
   DigitalID and lineage field semantics, refines Body canonicalization
   rules, and incorporates corrections identified through SDLP Fixture
   Bundle v4 testing. This revision aligns the object format with the
   current SDLP Identity (-02), Lineage (-03), Lifecycle (-03), Security
   Architecture (-04), Architecture (-03), Overview (-01), and Physics
   Model (-00) drafts.

Status of This Memo

   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

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Canonical Object Envelope  . . . . . . . . . . . . . . . .   9
   4.  Canonical Encoding Grammar  . . . . . . . . . . . . . . .   14
   5.  Hashing and Signing Rules  . . . . . . . . . . . . . . . .  21
   6.  Validation Rules  . . . . . . . . . . . . . . . . . . . .   28
   7.  Security Considerations  . . . . . . . . . . . . . . . . .  35
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . .  38
   9.  Normative References  . . . . . . . . . . . . . . . . . .   39
   10. Informative References  . . . . . . . . . . . . . . . . .   41

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .   43

1.  Introduction

   The Secured Digital Lifecycle Protocol (SDLP) defines a unified
   identity, lineage, and lifecycle framework for digital objects.
   Identity‑02 establishes the immutable DigitalID assigned at object
   creation, and Lifecycle‑03 defines the canonical state machine and
   transition semantics governing how SDLP objects evolve over time.
   This document provides the third foundational pillar of the SDLP
   suite: the canonical object format.

   The SDLP object format defines the normative byte‑level
   representation used for hashing, signing, validation, and
   interoperability across SDLP implementations. All SDLP‑governed
   objects MUST follow the canonical encoding, field ordering, and
   serialization grammar defined in this specification. The object
   format ensures that identity inheritance, lineage extension, and
   lifecycle transitions produce deterministic and verifiable results.

   Earlier drafts of the SDLP object format introduced preliminary
   encoding concepts but lacked a complete canonical grammar,
   deterministic serialization rules, and interoperability guarantees
   required by Identity‑02 and Lifecycle‑03. Implementers identified
   inconsistencies in field ordering, normalization behavior, and
   hashing preimage construction that prevented reliable validation and
   cross‑system interoperability.

   Object‑Format‑08 maintains the frozen canonical envelope grammar
   introduced in earlier revisions and updates it to align with the
   current SDLP Identity‑02, Lineage‑03, Lifecycle‑03, Security‑04,
   Architecture‑03, Overview‑01, and Physics‑00 drafts. The envelope has
   exactly one valid byte sequence: four U+000A separators, no trailing
   U+000A after Body, field values that MUST NOT contain CR or LF, and a
   Body encoded using unpadded base64url as defined in RFC 4648
   Section 5. Hashing and signing are performed over this exact byte
   sequence without normalization. This frozen grammar ensures that all
   SDLP implementations compute identical preimages, digests, and
   signatures for the same logical object.

   To aid implementers and reviewers, this revision introduces updated
   examples of fully serialized SDLP objects. These examples illustrate
   how DigitalID, InstanceID, Lineage, Timestamp, and Body appear in
   practice when encoded using the frozen canonical grammar and updated
   field semantics.

   SDLP objects are designed for systems that require tamper‑evident
   provenance, auditability, and lifecycle accountability. Typical
   applications include regulated‑content workflows, digital media
   provenance, software distribution lineage, and transparency‑log
   ecosystems. In these environments, multiple independent
   implementations—such as content‑authenticity services, audit
   platforms, or provenance registries—MAY interoperate by exchanging
   SDLP objects or by consuming their canonical digests. SDLP does not
   require any specific external system, but provides a stable,
   deterministic encoding suitable for cross‑vendor interoperability.

   The canonical object format defined in this document is REQUIRED for:

      * DigitalID encoding (Identity‑02),
      * lifecycle transition validation (Lifecycle‑03),
      * lineage extension and ancestry representation (Lineage‑03),
      * tamper‑evident hashing and signing (Security‑04),
      * transparency receipts and auditability.

   All SDLP implementations MUST treat the object format defined in this
   document as normative. Any deviation from the canonical encoding,
   field ordering, or serialization grammar constitutes a violation of
   SDLP semantics and MUST be rejected by relying parties.

   This document updates and replaces draft‑norton‑sdlp‑obj‑format‑07
   and provides the authoritative definition of the SDLP object format
   required for interoperable identity, lineage, and lifecycle
   processing.

2.  Terminology

   The following terms are used throughout this document. All terms are
   descriptive unless explicitly marked as normative. Identity-related
   terms are defined in draft-norton-sdlp-identity-02 and lifecycle
   terms are defined in draft-norton-sdlp-lifecycle-03. This section
   defines terminology specific to the SDLP object format.

   Canonical Representation:
      The normative byte-level encoding of an SDLP object. Canonical
      representation is deterministic, stable, and used for hashing,
      signing, validation, and interoperability. All SDLP objects MUST
      be serialized using the canonical representation defined in this
      document. Object-Format-08 maintains the frozen canonical grammar
      so that each logical object has exactly one valid byte sequence.

   Object Envelope:
      The top-level structure of an SDLP object. The envelope contains
      the DigitalID, InstanceID, Lineage, Timestamp, and the object
      body. The envelope is serialized using the canonical encoding
      grammar defined in Section 4, which specifies exactly four U+000A
      separators and prohibits any trailing U+000A after Body.

   Object Header:
      The portion of the object envelope containing DigitalID,
      InstanceID, Lineage, and Timestamp. The header is always encoded
      before the object body and follows strict field ordering rules.

   Object Body:
      The content, payload, or data associated with an SDLP object. The
      body may represent media, metadata, structured data, or any other
      digital content. The body is included in canonical representation
      and MUST follow the encoding rules defined in this specification,
      including unpadded base64url encoding as defined in RFC 4648
      Section 5.

   Field Ordering:
      The normative sequence in which fields MUST appear in the canonical
      representation. Field ordering is fixed and MUST NOT vary across
      implementations. Any deviation constitutes a canonicalization
      error.

   Serialization Grammar:
      The normative encoding rules governing how fields, values, arrays,
      and nested structures are serialized. The serialization grammar
      ensures deterministic byte-level output across all SDLP
      implementations. The grammar defined in Object-Format-08 is
      frozen and MUST NOT be altered by implementations.

   Hashing Preimage:
      The exact byte sequence used as input to cryptographic hash
      functions. The hashing preimage MUST be the canonical envelope
      defined in Section 4. Any other input is invalid.

   Signing Preimage:
      The exact byte sequence used as input to digital signature
      algorithms. The signing preimage MUST be identical to the hashing
      preimage unless otherwise specified by Security-04.

   Normalization:
      The process of converting an SDLP object into its canonical
      representation. Normalization MUST be deterministic and MUST NOT
      alter semantic content. Normalization rules are defined in
      Section 4. Verifiers MUST validate signatures over the received
      bytes and MUST NOT normalize input prior to verification.

   Deterministic Encoding:
      An encoding process that produces identical byte sequences for
      identical logical objects across all compliant implementations.
      Deterministic encoding is REQUIRED for hashing, signing, and
      interoperability.

   Relying Party:
      Any system that consumes SDLP objects and performs validation,
      verification, or admission decisions based on canonical
      representation, identity, lineage, or lifecycle metadata.

   SCITT:
      The IETF Secure Credential Infrastructure for Transparent Trust.
      SCITT profiles MAY carry the digest of the canonical envelope for
      transparency receipts and auditability. SCITT does not require the
      SDLP envelope itself, and does not mandate SDLP-specific encoding.

   EMILIA:
      An external provenance and authenticity framework. EMILIA profiles
      MAY incorporate the digest of the canonical envelope for
      cross-system interoperability. EMILIA does not require the SDLP
      encoding and does not mandate SDLP-specific serialization.

   Canonical Error:
      Any deviation from the canonical representation, field ordering,
      or serialization grammar. Canonical errors MUST cause relying
      parties to reject the object.

3.  Canonical Object Envelope

   The canonical object envelope defines the top-level structure of all
   SDLP-governed objects. The envelope contains the identity fields,
   lifecycle fields, and object body, all serialized using the canonical
   encoding grammar defined in Section 4. The envelope is the normative
   unit of hashing, signing, validation, and interoperability.

   Object-Format-08 freezes the canonical envelope grammar. The envelope
   has exactly one valid byte sequence: four U+000A separators, no
   trailing U+000A after Body, field values that MUST NOT contain CR or
   LF, and a Body encoded using unpadded base64url as defined in RFC
   4648 Section 5. Hashing and signing are performed over this exact
   byte sequence without normalization. Any deviation constitutes a
   canonicalization error and MUST cause relying parties to reject the
   object.

3.1.  Envelope Structure

   An SDLP object envelope consists of the following components:

      * DigitalID
      * InstanceID
      * Lineage
      * Timestamp
      * Body

   These components MUST appear in the canonical representation in the
   exact order listed above. Field ordering is normative and MUST NOT be
   altered by any implementation.

   The canonical envelope is represented conceptually as:

      Envelope := {
         DigitalID,
         InstanceID,
         Lineage,
         Timestamp,
         Body
      }

   The envelope is serialized using the deterministic encoding grammar
   defined in Section 4. The envelope MUST NOT include optional fields,
   alternative encodings, or implementation-specific metadata. The
   grammar defined in this document is frozen and MUST NOT be altered by
   implementations.

3.2.  DigitalID Component

   DigitalID is the immutable identity tuple defined in Identity-02.
   DigitalID uniquely identifies the origin object and is inherited
   unchanged by all descendants.

   DigitalID MUST appear first in the canonical envelope. DigitalID MUST
   be encoded using the canonical grammar defined in Identity-02 and
   MUST NOT be modified, reordered, or re-encoded during lifecycle
   transitions.

3.3.  InstanceID Component

   InstanceID is the per-object identifier assigned at each lifecycle
   transition. InstanceID MUST follow the hierarchical grammar defined
   in draft-norton-sdlp-lifecycle-03.

   InstanceID MUST appear immediately after DigitalID in the canonical
   envelope. InstanceID MUST be encoded as a canonical string using the
   serialization grammar defined in Section 4.

3.4.  Lineage Component

   Lineage reflects the complete ancestry of the object. Lineage MUST
   follow the hierarchical grammar defined in draft-norton-sdlp-lifecycle-03
   and MUST grow deterministically with each lifecycle transition.

   Lineage MUST appear immediately after InstanceID in the canonical
   envelope. Lineage MUST be encoded as a canonical string using the
   serialization grammar defined in Section 4.

3.5.  Timestamp Component

   Timestamp reflects the moment the lifecycle transition occurred.
   Timestamp MUST follow the canonical grammar defined in Lifecycle-03:

      Date := YYYY-MM-DD
      Time := HH:MM:SS
      Timestamp := Date "T" Time

   Timestamp MUST appear immediately after Lineage in the canonical
   envelope. Timestamp MUST be encoded as a canonical string. Timestamp
   values MUST NOT contain CR, LF, or timezone suffixes.

3.6.  Body Component

   The Body contains the content, payload, or data associated with the
   SDLP object. The Body may represent media, metadata, structured data,
   or any other digital content.

   The Body MUST appear last in the canonical envelope. The Body MUST be
   encoded using the canonical serialization grammar defined in Section
   4, including unpadded base64url encoding. The Body MUST NOT contain
   CR or LF. The Body MUST be included in the hashing and signing
   preimage, and no trailing U+000A MUST follow the Body.

3.7.  Envelope Determinism Requirements

   The canonical envelope is deterministic if and only if:

      * all fields appear in the normative order,
      * all fields are encoded using the canonical grammar,
      * no optional fields or alternative encodings are present,
      * DigitalID is preserved exactly,
      * InstanceID, Lineage, and Timestamp follow Lifecycle-03 rules,
      * the Body is encoded deterministically using unpadded base64url,
      * exactly four U+000A separators are present,
      * no trailing U+000A follows the Body.

   Deterministic envelopes are REQUIRED for hashing, signing,
   interoperability, and validation.

3.8.  Envelope Validation

   A relying party MUST validate the canonical envelope before accepting
   an SDLP object. Envelope validation MUST ensure:

      * field ordering is correct,
      * DigitalID is valid (Identity-02),
      * InstanceID and Lineage follow canonical grammar,
      * Timestamp is well-formed,
      * Body is encoded canonically using unpadded base64url,
      * exactly four U+000A separators are present,
      * no trailing U+000A follows the Body,
      * no extraneous fields or metadata are present.

   Envelope validation failures MUST cause the object to be rejected.

3.9.  Example SDLP Object

   The following example illustrates a fully serialized SDLP object
   encoded using the frozen canonical grammar. The example shows the
   exact five-field, LF-delimited canonical envelope with unpadded
   base64url Body encoding and no trailing U+000A.

   dist123/cust456/prod789/MovieTitle/dl001/2026-07-27T14:32:10
   1.4
   1.4
   2026-08-01T08:30:15
   SGVsbG8sIFNETFAh

   SHA-256: 4e121057d46afec547e04ec63194ffd8a1e27178e06ba563b760fb35a436f32b

   In this example:

      * DigitalID is "dist123/cust456/prod789/MovieTitle/dl001/2026-07-27T14:32:10",
      * InstanceID is "1.4",
      * Lineage is "1.4",
      * Timestamp is "2026-08-01T08:30:15",
      * Body is the unpadded base64url encoding of the UTF-8 string
        "Hello, SDLP!".

   This example is provided for illustration only. All SDLP objects MUST
   follow the frozen canonical grammar defined in this document.

4.  Canonical Encoding Grammar

   The canonical encoding grammar defines the normative byte-level
   serialization rules for all SDLP objects. The grammar ensures that
   every SDLP implementation produces identical canonical representations
   for identical logical objects, enabling deterministic hashing,
   signing, validation, and interoperability.

   Object-Format-08 freezes the canonical encoding grammar. The grammar
   defines exactly one valid byte sequence for each logical object:
   four U+000A separators, no trailing U+000A after Body, field values
   that MUST NOT contain CR or LF, and a Body encoded using unpadded
   base64url as defined in RFC 4648 Section 5. Hashing and signing are
   performed over this exact byte sequence without normalization.

   All SDLP-governed objects MUST be serialized using the canonical
   encoding grammar defined in this section. Any deviation constitutes a
   canonicalization error and MUST cause relying parties to reject the
   object.

4.1.  Deterministic Serialization Requirements

   Canonical serialization MUST satisfy the following requirements:

      * deterministic: identical logical objects produce identical bytes,
      * stable: encoding rules MUST NOT vary across implementations,
      * complete: all fields in the envelope MUST be serialized,
      * ordered: fields MUST appear in the normative sequence defined in
        Section 3,
      * unambiguous: no optional fields, alternative encodings, or
        implementation-specific metadata are permitted,
      * strict: whitespace, formatting, and structural rules MUST be
        applied exactly.

   Deterministic serialization is REQUIRED for hashing, signing,
   lifecycle validation, and interoperability. SCITT and EMILIA profiles
   MAY incorporate the digest of the canonical envelope; neither system
   requires the SDLP envelope itself.

4.2.  Encoding Model

   SDLP uses a strict, text-based canonical encoding model. All fields
   are serialized as UTF-8 strings using the grammar defined in this
   section. No binary encodings, compression schemes, or alternative
   serialization formats are permitted.

   The canonical representation is conceptually:

      Canonical := DigitalID "\n"
                   InstanceID "\n"
                   Lineage "\n"
                   Timestamp "\n"
                   Body

   where each component is encoded using the rules defined below. The
   grammar is frozen and MUST NOT be altered by implementations.

4.3.  String Encoding Rules

   All SDLP fields MUST be encoded as UTF-8 strings. The following rules
   apply:

      * no leading or trailing whitespace,
      * no indentation or formatting characters,
      * no optional whitespace between tokens,
      * no alternative quoting or escaping conventions,
      * no normalization beyond UTF-8 encoding,
      * field values MUST NOT contain CR or LF.

   Strings MUST be encoded exactly as defined in Identity-02 and
   Lifecycle-03.

4.4.  Field Ordering Rules

   Fields MUST appear in the canonical representation in the following
   order:

      1. DigitalID
      2. InstanceID
      3. Lineage
      4. Timestamp
      5. Body

   Field ordering is normative. Any deviation constitutes a canonical
   error.

4.5.  DigitalID Encoding

   DigitalID MUST be encoded using the canonical grammar defined in
   Identity-02. DigitalID MUST appear exactly as assigned at origin and
   MUST NOT be modified during lifecycle transitions.

   DigitalID MUST be encoded as a single UTF-8 string.

4.6.  InstanceID Encoding

   InstanceID MUST be encoded using the hierarchical grammar defined in
   Lifecycle-03:

      InstanceID := number *( "." number )

   InstanceID MUST be encoded as a single UTF-8 string with no
   whitespace, padding, or alternative separators.

4.7.  Lineage Encoding

   Lineage MUST be encoded using the hierarchical grammar defined in
   Lifecycle-03:

      Lineage := number *( "." number )

   Lineage MUST reflect the complete ancestry of the object and MUST be
   encoded as a single UTF-8 string.

4.8.  Timestamp Encoding

   Timestamp MUST follow the canonical grammar defined in Lifecycle-03:

      Date := YYYY "-" MM "-" DD
      Time := HH ":" MM ":" SS
      Timestamp := Date "T" Time

   Timestamp MUST be encoded as a single UTF-8 string. Timestamp values
   MUST NOT contain CR, LF, or timezone suffixes.

4.9.  Body Encoding

   The Body contains the object’s content or payload. The Body MUST be
   encoded as a UTF-8 string using the following rules:

      * Body MUST NOT contain leading or trailing whitespace,
      * Body MUST NOT contain indentation or formatting artifacts,
      * Body MUST NOT contain implementation-specific metadata,
      * Body MUST NOT contain CR or LF,
      * Body MUST be included exactly as provided by the lifecycle
        transition.

   Binary Bodies (e.g., media, structured data, or arbitrary byte
   sequences) MUST be encoded using URL-safe Base64 without padding.
   The Base64 value MUST represent the exact raw bytes of the Body and
   MUST be included verbatim in the canonical representation.

4.10.  Canonical Newline Rules

   The canonical representation MUST use the newline character:

      "\n" (U+000A)

   Newlines MUST appear only between the envelope fields defined in
   Section 3. Newlines MUST NOT appear within DigitalID, InstanceID,
   Lineage, or Timestamp.

   The canonical envelope contains exactly four U+000A separators and
   MUST NOT contain a trailing U+000A after Body. Any other newline
   placement constitutes a canonicalization error.

4.11.  Prohibited Encodings

   The following encodings MUST NOT be used:

      * JSON, CBOR, XML, or other structured formats,
      * binary encodings,
      * compression formats,
      * whitespace-normalized formats,
      * implementation-specific serialization schemes.

   Any prohibited encoding constitutes a canonical error.

4.12.  Canonicalization Errors

   A relying party MUST reject an SDLP object if:

      * field ordering is incorrect,
      * any field violates its encoding grammar,
      * whitespace rules are violated,
      * prohibited encodings are used,
      * DigitalID is modified or re-encoded,
      * InstanceID or Lineage violate hierarchical grammar,
      * Timestamp is malformed,
      * Body is not encoded canonically,
      * newline placement violates Section 4.10.

   Canonicalization errors MUST be surfaced to the relying party or
   verifier.

5.  Hashing and Signing Rules

   This section defines the normative hashing and signing rules for all
   SDLP objects. Hashing and signing provide tamper-evident integrity,
   lifecycle accountability, and interoperability with external
   provenance systems. Object-Format-08 freezes the hashing and signing
   preimage to ensure that each logical object has exactly one valid
   byte sequence.

   All SDLP implementations MUST compute hashes and signatures using the
   canonical representation defined in Section 4. Any deviation
   constitutes a canonicalization error and MUST cause relying parties
   to reject the object.

5.1.  Hashing Preimage

   The hashing preimage is the exact byte sequence used as input to
   cryptographic hash functions. The hashing preimage MUST be:

      HashPreimage := CanonicalEnvelope

   where CanonicalEnvelope is the deterministic, five-field, LF-delimited
   SDLP envelope defined in Section 4.

   The hashing preimage MUST include:

      * DigitalID,
      * InstanceID,
      * Lineage,
      * Timestamp,
      * Body (unpadded base64url of raw bytes),
      * exactly four U+000A separators.

   The hashing preimage MUST represent the canonical envelope exactly as
   serialized. A trailing U+000A after the Body MUST NOT appear in the
   canonical envelope and MUST NOT be included in the hashing preimage.

   The hashing preimage MUST NOT include:

      * non-canonical whitespace,
      * implementation-specific metadata,
      * alternative encodings (including JSON, CBOR, XML),
      * signature envelopes,
      * compression artifacts,
      * any normalization beyond UTF-8 encoding.

   Hashing MUST be performed over the exact canonical byte sequence with
   no trimming, transformation, reinterpretation, or normalization.

5.2.  Hash Function Requirements

   SDLP does not mandate a specific hash algorithm, but all compliant
   implementations MUST use a cryptographic hash function that:

      * is collision-resistant,
      * is preimage-resistant,
      * is widely deployed and audited,
      * produces a fixed-length output.

   SHA-256 is RECOMMENDED for interoperability with external provenance
   systems.

   Relying parties MUST reject objects hashed with non-cryptographic or
   deprecated algorithms.

5.3.  Signing Preimage

   The signing preimage is the exact byte sequence used as input to
   digital signature algorithms. The signing preimage MUST be identical
   to the hashing preimage:

      SigningPreimage := HashPreimage

   unless otherwise specified by SDLP Security-04.

   Implementations MUST NOT sign:

      * non-canonical representations,
      * partial envelopes,
      * modified or normalized variants,
      * metadata not included in the canonical envelope,
      * alternative encodings of the Body.

   Signatures MUST be computed over the canonical byte sequence exactly.
   The signature MUST cover the complete LF-delimited SDLP envelope,
   including all four U+000A separators and the unpadded base64url Body
   value representing the exact raw bytes of the object.

5.4.  Signature Envelope

   A signature envelope contains the digital signature and associated
   metadata. The signature envelope MUST NOT be included in the hashing
   or signing preimage.

   The signature envelope MAY contain:

      * signature algorithm identifier,
      * public key identifier,
      * signature value,
      * optional certificate chain.

   Signature envelopes MUST NOT modify, replace, or reinterpret the
   canonical representation.

5.5.  Verification Rules

   A relying party MUST verify signatures using the following procedure:

      1. Parse the received bytes exactly as provided.
      2. Confirm that the received bytes satisfy the canonical grammar
         defined in Section 4.
      3. Compute the hash over the received canonical envelope bytes.
      4. Verify the signature using the SigningPreimage.
      5. Validate DigitalID, InstanceID, Lineage, and Timestamp.
      6. Validate lifecycle state and transition correctness (Lifecycle-03).

   Verification MUST fail if:

      * canonicalization fails,
      * the signature does not match the SigningPreimage,
      * the hash does not match the canonical envelope,
      * DigitalID is modified or re-encoded,
      * InstanceID or Lineage violate canonical grammar,
      * Timestamp is malformed,
      * Body is not encoded as unpadded base64url of raw bytes.

   Verifiers MUST NOT normalize input prior to signature verification.
   Acceptance requires byte equality between the received envelope and
   the hashing/signing preimage.

5.6.  SCITT and EMILIA Interoperability

   SDLP achieves interoperability with external provenance systems by:

      * using a stable canonical encoding grammar,
      * defining a single hashing preimage,
      * defining a single signing preimage,
      * prohibiting alternative encodings,
      * prohibiting metadata in the canonical envelope.

   SCITT and EMILIA profiles MAY incorporate the digest of the canonical
   envelope. Neither system requires the SDLP envelope itself, and no
   external system mandates SDLP-specific encoding.

5.7.  Hashing and Signing Errors

   A relying party MUST reject an SDLP object if:

      * the hashing preimage is non-canonical,
      * the signature is computed over a non-canonical representation,
      * the signature envelope modifies canonical fields,
      * the hash does not match the canonical envelope,
      * the signature fails verification,
      * prohibited encodings are used,
      * the Body is not encoded as unpadded base64url of raw bytes.

   Hashing and signing errors MUST be surfaced to the verifier or
   relying party.

6.  Validation Rules

   Validation ensures that SDLP objects conform to the canonical
   representation, identity semantics, lineage grammar, and lifecycle
   rules defined across the SDLP specification suite. Relying parties,
   verifiers, and SDLP-aware systems MUST apply the validation procedures
   described in this section before accepting any SDLP object as
   admissible.

   Validation MUST be performed over the received canonical envelope
   bytes. Verifiers MUST NOT normalize input prior to validation. Any
   deviation from canonical encoding, field ordering, or serialization
   grammar constitutes a validation failure.

6.1.  Validation Preconditions

   A relying party MUST parse the received bytes exactly as provided and
   confirm that those bytes satisfy the canonical grammar defined in
   Section 4. Validation MUST NOT be performed over normalized,
   reconstructed, partially canonical, or alternative encodings.

   Validation MUST ensure:

      * the envelope is well-formed,
      * all required fields are present,
      * field ordering is correct,
      * no prohibited fields or metadata are present,
      * DigitalID is valid (Identity-02),
      * InstanceID and Lineage follow hierarchical grammar (Lifecycle-03),
      * Timestamp is well-formed and contains no timezone suffix,
      * Body is encoded canonically as unpadded base64url of raw bytes,
      * exactly four U+000A separators are present,
      * no trailing U+000A follows the Body.

6.2.  Envelope Validation

   Envelope validation ensures that the top-level structure of the SDLP
   object conforms to Section 3. Envelope validation MUST verify:

      * DigitalID appears first,
      * InstanceID appears second,
      * Lineage appears third,
      * Timestamp appears fourth,
      * Body appears last,
      * each field is encoded as a UTF-8 string,
      * field values contain no CR or LF,
      * newline separators follow canonical rules (U+000A),
      * the envelope consists of exactly five fields and four separators,
      * no trailing U+000A follows the Body,
      * no additional fields or metadata are present.

   Envelope validation failures MUST cause the object to be rejected.

6.3.  Identity Validation

   Identity validation ensures that DigitalID is preserved exactly across
   lifecycle transitions. Identity validation MUST verify:

      * Child.DigitalID == Parent.DigitalID (byte-wise equality),
      * no DigitalID fields differ,
      * no DigitalID fields have been regenerated or replaced,
      * DigitalID conforms to Identity-02 encoding grammar.

   Identity validation failures MUST cause the object to be rejected.

6.4.  InstanceID Validation

   InstanceID validation ensures that lifecycle transitions follow the
   canonical hierarchical grammar. InstanceID validation MUST verify:

      * InstanceID := number *( "." number ),
      * InstanceID extends the parent InstanceID by appending "." ChildIndex,
      * ChildIndex is a positive integer,
      * ChildIndex is unique among siblings,
      * no truncation, rewriting, or reordering has occurred.

   InstanceID validation failures MUST cause the object to be rejected.

6.5.  Lineage Validation

   Lineage validation ensures that ancestry is preserved and extended
   deterministically. Lineage validation MUST verify:

      * Lineage := number *( "." number ),
      * Lineage extends the parent Lineage by appending "." ChildIndex,
      * Lineage reflects complete ancestry,
      * no truncation or rewriting has occurred,
      * no malformed segments are present.

   Lineage validation failures MUST cause the object to be rejected.

6.6.  Timestamp Validation

   Timestamp validation ensures that lifecycle transitions record the
   correct moment of creation. Timestamp validation MUST verify:

      * Timestamp := YYYY-MM-DD "T" HH:MM:SS,
      * Timestamp is well-formed,
      * Timestamp contains no timezone suffix,
      * Timestamp is not reused across transitions,
      * Timestamp is distinct from the immutable Date and Time fields in
        DigitalID.

   Timestamp validation failures MUST cause the object to be rejected.

6.7.  Body Validation

   Body validation ensures that the object’s content is encoded
   canonically. Body validation MUST verify:

      * Body is encoded as a UTF-8 string,
      * Body contains no leading or trailing whitespace,
      * Body contains no indentation or formatting artifacts,
      * Body contains no implementation-specific metadata,
      * Body contains no CR or LF,
      * Body is encoded as unpadded base64url (RFC 4648 §5),
      * the Base64 value represents the exact raw bytes of the object’s
        content,
      * Body is included exactly as provided by the lifecycle transition.

   Body validation failures MUST cause the object to be rejected.

6.8.  Hash and Signature Validation

   Hash and signature validation MUST follow Section 5. Relying parties
   MUST verify:

      * the hash is computed over the received canonical envelope bytes,
      * the signature is computed over the received canonical envelope,
      * the signature envelope does not modify canonical fields,
      * the signature matches the SigningPreimage,
      * the hash matches the canonical envelope exactly,
      * all newline separators are canonical (U+000A),
      * the Body is the exact unpadded base64url value included in the
        canonical envelope.

   Hash or signature validation failures MUST cause the object to be
   rejected.

6.9.  Canonicalization Errors

   A relying party MUST reject an SDLP object if any of the following
   canonicalization errors occur:

      * incorrect field ordering,
      * malformed DigitalID, InstanceID, Lineage, or Timestamp,
      * prohibited encodings (JSON, CBOR, XML, binary),
      * non-canonical whitespace,
      * missing or extraneous fields,
      * modified DigitalID,
      * malformed hierarchical grammar,
      * Body not encoded as unpadded base64url of raw bytes,
      * incorrect newline placement,
      * malformed canonical envelope.

   Canonicalization errors MUST be surfaced to the verifier or relying
   party.

7.  Security Considerations

   The SDLP object format provides the foundation for tamper-evident
   identity, lineage, and lifecycle guarantees across all SDLP
   implementations. Security in SDLP depends critically on the
   deterministic canonical representation defined in this document.
   Incorrect, inconsistent, or non-canonical encodings directly weaken
   SDLP’s integrity model and MUST be rejected by relying parties.

7.1.  Canonical Representation Integrity

   The canonical encoding grammar defined in Section 4 ensures that all
   SDLP objects produce identical byte-level representations across
   implementations. Deterministic canonical representation is REQUIRED
   for hashing, signing, lifecycle validation, and interoperability.

   The canonical envelope consists of exactly five UTF-8 fields separated
   by four LF (U+000A) characters, with the Body encoded as unpadded
   base64url of raw bytes. Any deviation from this representation—such
   as alternative whitespace, field reordering, malformed Base64, or
   non-canonical serialization—constitutes a security violation.
   Relying parties MUST reject objects that fail canonicalization.

7.2.  Hashing and Signing Integrity

   Hashing and signing rules defined in Section 5 ensure that SDLP
   objects cannot be modified without detection. Security depends on the
   following invariants:

      * the hashing preimage MUST be the canonical envelope,
      * the signing preimage MUST be identical to the hashing preimage,
      * signatures MUST NOT be computed over non-canonical encodings,
      * signature envelopes MUST NOT modify canonical fields,
      * newline separators MUST be canonical (U+000A),
      * the Body MUST be the exact unpadded base64url value included in
        the envelope.

   If an attacker attempts to alter DigitalID, InstanceID, Lineage,
      Timestamp, or Body, the canonical hash will change and signature
      verification will fail. Relying parties MUST treat any mismatch as a
      tampering event.

7.3.  Identity and Lineage Integrity

   Identity-02 and Lifecycle-03 define strict rules for DigitalID,
   InstanceID, and Lineage. The object format enforces these rules by
   requiring:

      * DigitalID to be preserved exactly (byte-wise equality),
      * InstanceID to follow hierarchical grammar,
      * Lineage to reflect complete ancestry,
      * Timestamp to be unique per transition.

   Incorrect identity or lineage encoding can cause misattribution,
   ancestry confusion, or lifecycle ambiguity. Relying parties MUST
   reject objects whose identity or lineage fields violate canonical
   grammar.

7.4.  Replay Considerations

   SDLP does not, by itself, prevent replay attacks. A correctly signed
   canonical envelope can be replayed byte-for-byte. Unique InstanceID,
   Lineage, and Timestamp values detect modification, but they do not
   establish freshness or one-time use.

   Replay resistance requires relying-party state, such as:

      * an accepted-InstanceID registry,
      * monotonic lineage tracking,
      * nonce or challenge mechanisms,
      * transparency-log uniqueness checks,
      * atomic one-time consumption semantics.

   A stateless verifier can only report that the object is authentic and
   previously well-formed.

7.5.  BitDrop Conditions

   SDLP defines a BitDrop as any event that attempts to rewrite,
   truncate, substitute, or downgrade identity, lineage, or canonical
   representation. BitDrop events violate SDLP lifecycle semantics and
   MUST be rejected before hashing, signing, or validation occur.

   The following conditions constitute a BitDrop:

      * replacing a child object with its parent,
      * truncating lineage to hide ancestry,
      * rewriting InstanceID to alter transition order,
      * modifying Timestamp to obscure event timing,
      * substituting non-canonical encodings,
      * injecting metadata into the canonical envelope,
      * altering DigitalID in any way,
      * altering the Base64 Body value or its underlying raw bytes.

   BitDrop events are invalid lifecycle-transition attempts and MUST be
   rejected, logged, and surfaced to policy. They are relevant to threat
   modeling because adversaries may submit them.

7.6.  Metadata Injection Protection

   SDLP prohibits optional fields, alternative encodings, and
   implementation-specific metadata. Metadata injection attacks may
   attempt to:

      * embed hidden fields in the envelope,
      * alter whitespace or formatting,
      * introduce non-canonical serialization artifacts,
      * add fields that influence downstream processing,
      * modify the Base64 Body value or introduce padding.

   Relying parties MUST reject any object containing extraneous fields,
   metadata, or non-canonical formatting.

7.7.  Interoperability Security

   SDLP achieves interoperability with external provenance systems by
   defining a stable canonical envelope, a single hashing preimage, and
   a single signing preimage. SCITT and EMILIA profiles MAY incorporate
   the digest of the canonical envelope. Neither system requires the
   SDLP envelope itself, and no external system mandates SDLP-specific
   encoding.

   Any deviation from canonical representation undermines cross-system
   validation and MUST be treated as a security failure.

7.8.  Implementation Guidance

   Implementers SHOULD:

      * validate canonical representation before processing,
      * reject non-canonical encodings early,
      * use audited cryptographic libraries,
      * ensure UTF-8 correctness and stability,
      * ensure Base64 encoding is URL-safe and unpadded.

   Implementers MUST NOT:

      * modify DigitalID during transitions,
      * rewrite InstanceID or Lineage,
      * alter Timestamp semantics,
      * introduce optional or vendor-specific fields,
      * use non-canonical serialization formats,
      * alter newline separators,
      * alter the Base64 Body value.

7.9.  Summary

   The SDLP object format is a security-critical component of the SDLP
   architecture. Deterministic canonical representation, strict field
   ordering, canonical newline rules, unpadded base64url Body encoding,
   and stable hashing and signing rules ensure that SDLP objects remain
   tamper-evident, verifiable, and interoperable across all
   implementations. Relying parties MUST enforce canonicalization and
   validation to maintain SDLP’s security guarantees.

8.  IANA Considerations

   This document has no IANA actions.

   SDLP does not define protocol parameters, registries, code points, or
   other values requiring IANA allocation or management. All identifiers
   used in SDLP (DigitalID, InstanceID, Lineage, Timestamp) are defined
   deterministically by SDLP specifications and do not require external
   registration.

   Future SDLP documents MAY introduce optional registries for object
   types, transformation classes, or provenance metadata. Any such
   registries would be defined in their respective documents and are not
   required by the canonical object format.

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

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648,
              October 2006.

   [SDLP-Identity-02]
              Norton, M., "SDLP Identity Specification",
              draft-norton-sdlp-identity-02, July 2026.

   [SDLP-Lifecycle-03]
              Norton, M., "SDLP Lifecycle State Machine and Transition
              Rules", draft-norton-sdlp-lifecycle-03, July 2026.

   [SDLP-Lineage-03]
              Norton, M., "SDLP Lineage Structure and Ancestry Grammar",
              draft-norton-sdlp-lineage-03 (work in progress),
              July 2026.

   [SCITT-Architecture]
              IETF SCITT Working Group, "SCITT Architecture",
              draft-ietf-scitt-architecture, work in progress.

10.  Informative References

   [SDLP-Architecture]
              Norton, M., "SDLP Architectural Overview",
              draft-norton-sdlp-architecture-03 (work in progress),
              July 2026.

   [SDLP-Overview-01]
              Norton, M., "SDLP Overview",
              draft-norton-sdlp-overview-01 (work in progress),
              July 2026.

   [SDLP-Physics-00]
              Norton, M., "SDLP Representation, Semantics, and Physical Mapping",
              draft-norton-sdlp-physics-00 (work in progress), July 2026.

   [SCITT-Use-Cases]
              IETF SCITT Working Group, "SCITT Use Cases",
              draft-ietf-scitt-use-cases, work in progress.

   [C2PA]
              Coalition for Content Provenance and Authenticity (C2PA),
              "C2PA Specification", Version 2.0, 2025.

   [W3C-VC]
              World Wide Web Consortium, "Verifiable Credentials Data
              Model", W3C Recommendation, 2022.

   [W3C-DID]
              World Wide Web Consortium, "Decentralized Identifiers
              (DIDs) v1.0", W3C Recommendation, 2022.

   [NIST-Hash]
              National Institute of Standards and Technology,
              "Secure Hash Standard (SHS)", FIPS PUB 180-4, 2015.

   [NIST-Digital-Signatures]
              National Institute of Standards and Technology,
              "Digital Signature Standard (DSS)", FIPS PUB 186-5, 2023.

13.  Revision History

   draft-norton-sdlp-obj-format-08

      * Updated canonical grammar references to align with
        Identity-02, Lineage-03, Lifecycle-03, Security-04,
        Architecture-03, Overview-01, and Physics-00.

      * Updated terminology and validation rules to reference
        Lifecycle-03 instead of Lifecycle-02.

      * Clarified canonical envelope invariants and newline rules
        consistent with the frozen grammar.

      * Updated hashing and signing rules to reference Security-04
        and to reinforce byte-for-byte SigningPreimage equality.

      * Updated examples to reflect current SDLP field semantics and
        canonical encoding behavior.

      * Incorporated corrections identified during SDLP Fixture
        Bundle v4 testing (non-normative).

   draft-norton-sdlp-obj-format-07

      * Introduced frozen canonical envelope grammar.
      * Defined deterministic LF-delimited five-field envelope.
      * Added canonical newline, whitespace, and Base64 rules.
      * Added hashing and signing preimage definitions.
      * Added example canonical envelope.

Author's Address

   M. Norton
   Independent
   El Mirage, Arizona, USA

   Email: mark433norton@gmail.com