SDLP Interoperability Profile for Ownership and Provenance
draft-norton-sdlp-interop-profile-00

Internet-Draft                                                 M. Norton
Intended status: Informational                               Independent
Expires: 28 January 2027                                   28 July 2026

        SDLP Interoperability Profile for Ownership and Provenance
               draft-norton-sdlp-interop-profile-00

M. Norton
Independent
El Mirage, Arizona, USA
Email: mark433norton@gmail.com
28 July 2026

Abstract

   This document defines an interoperability profile for the Secured
   Digital Lifecycle Protocol (SDLP). The profile specifies how SDLP
   canonical objects, identity, lineage, lifecycle state, and digests
   are composed with ownership binding, trust-root pinning, and
   relying-party admission semantics. It defines a transition vector
   model, a binding result vocabulary, and composition rules for
   integrating SDLP with provenance and transparency systems such as
   CAID, AEC, AEB, SCITT, and EMILIA, without changing the core SDLP
   semantics.

Copyright (c) 2026 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

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.

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SDLP Canonical Envelope (Imported Semantics)  . . . . . . . .   5
   3.  Interoperability Profile Model  . . . . . . . . . . . . . . .   8
   4.  OwnershipBinding Event Semantics  . . . . . . . . . . . . . .  12
   5.  Trust-Root Pinning and Signer Metadata  . . . . . . . . . . .  18
   6.  Binding Result Vocabulary and Relying-Party Decisions  . . .  22
   7.  Transition Vectors  . . . . . . . . . . . . . . . . . . . . .  28
   8.  SCITT and EMILIA Composition Rules  . . . . . . . . . . . . .  36
   9.  Security Considerations  . . . . . . . . . . . . . . . . . .  42
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  45
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  46
   12. Informative References  . . . . . . . . . . . . . . . . . . .  48

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  50

1.  Introduction

   The Secured Digital Lifecycle Protocol (SDLP) defines a canonical
   representation for governed digital objects, including identity,
   lineage, lifecycle state, timestamps, and digests. The SDLP core
   specifications (Identity, Lineage, Lifecycle, and Object Format)
   intentionally do not define ownership binding semantics, trust-root
   profiles, or relying-party admission decisions.

   This document defines an interoperability profile that composes SDLP
   canonical objects with ownership binding, trust-root pinning, and
   admission semantics suitable for provenance and transparency systems.
   The profile introduces a transition vector model that carries SDLP
   canonical envelope fields, digests, and signature metadata, and
   defines a separate binding result vocabulary and relying-party
   decision semantics that are not part of SDLP itself.

   The goal of this profile is to enable interoperable use of SDLP in
   systems such as CAID, AEC, AEB, SCITT, and EMILIA, while preserving
   the separation of concerns between SDLP object semantics and
   ecosystem-specific admission and trust policies.

2.  SDLP Canonical Envelope (Imported Semantics)

   SDLP defines a canonical envelope for governed objects. The envelope
   is serialized in a deterministic order and used as the preimage for
   digest computation and signature generation. The canonical envelope
   consists of the following fields:

   *  DigitalID
   *  InstanceID
   *  Lineage
   *  Timestamp
   *  Body

   The precise semantics and validation rules for these fields are
   defined in the SDLP Identity, Lineage, Lifecycle, and Object Format
   specifications. This profile imports those semantics without change.

   For the purposes of this interoperability profile, the canonical
   envelope is treated as the authoritative representation of the
   governed object. All binding, trust, and admission semantics operate
   on the canonical envelope and its associated digest and signature
   metadata.

3.  Interoperability Profile Model

   This profile distinguishes between two layers:

   *  The SDLP layer, which defines canonical object semantics, identity,
      lineage, lifecycle state, timestamps, and digests.

   *  The interoperability layer, which defines ownership binding
      events, trust-root pinning, binding results, and relying-party
      admission decisions.

   SDLP does not define OwnershipBinding objects or events, signer or
   trust-root profiles, or SATISFIED/REFUSED/INDETERMINATE result
   vocabularies. Those concepts belong to the interoperability layer and
   are specified in this document.

   A transition vector, as used in this profile, is a structured
   artifact that carries:

   *  The SDLP canonical envelope fields and associated digest and
      signature metadata.

   *  Interoperability-layer metadata, including an owner_binding_ref,
      trust_root reference, binding_result, and relying-party decision
      state.

   The SDLP layer remains unchanged by this profile. All additional
   semantics are expressed in the interoperability layer and are
   designed to be composable with existing provenance and transparency
   systems.

4.  OwnershipBinding Event Semantics

   SDLP defines the canonical representation of governed objects,
   including identity, lineage, lifecycle state, timestamps, and
   digests. However, SDLP does not define ownership semantics or the
   conditions under which a relying party determines that an object is
   bound to a specific owner or trust domain. OwnershipBinding is
   therefore defined in this interoperability profile rather than in
   SDLP itself.

   An OwnershipBinding event establishes an initial association between
   a canonical SDLP object and an external owner or trust-root. The
   event does not modify the SDLP object; instead, it provides
   interoperability-layer metadata that enables relying parties to
   validate the origin, authenticity, and admission status of the
   object.

   An OwnershipBinding event MUST reference a canonical SDLP object by
   carrying the following fields:

   *  The SDLP canonical envelope (DigitalID, InstanceID, Lineage,
      Timestamp, Body).

   *  The digest computed over the exact canonical envelope bytes.

   *  Signature metadata sufficient to validate the signer of the
      canonical envelope.

   The OwnershipBinding event MUST also carry interoperability-layer
   metadata that is not part of SDLP semantics:

   *  owner_binding_ref: an identifier for the binding event.

   *  signer: the identity of the entity that produced the signature
      over the canonical envelope.

   *  trust_root: a reference to the trust anchor used to validate the
      signer.

   *  binding_result: a value from the vocabulary defined in Section 6
      indicating whether the binding is SATISFIED, REFUSED, or
      INDETERMINATE.

   OwnershipBinding validation consists of two independent checks:

   1.  SDLP canonical validation, which ensures that the referenced
       object is well-formed, canonical, and digest-correct according
       to SDLP Identity, Lineage, Lifecycle, and Object Format
       specifications.

   2.  Interoperability-layer validation, which ensures that the signer
       is authorized under the referenced trust_root and that the
       binding_result accurately reflects the relying-party admission
       decision.

   An OwnershipBinding event MUST NOT alter the SDLP canonical envelope
   or any SDLP-defined semantics. All binding and admission semantics
   are expressed exclusively in the interoperability layer.

   Negative OwnershipBinding events (e.g., REFUSED or INDETERMINATE)
   MUST carry the same canonical envelope and digest as the positive
   event, enabling relying parties to detect invalid SDLP lineage,
   altered DigitalID values, BitDrop conditions, or non-canonical
   preimages without ambiguity.

5.  Trust-Root Pinning and Signer Metadata

   SDLP defines the canonical envelope and digest computation rules for
   governed objects, but it does not define how signers are represented,
   how trust anchors are selected, or how relying parties validate the
   authenticity of a signature. These semantics belong to the
   interoperability layer and are specified in this section.

   A transition vector MUST include signer metadata sufficient for a
   relying party to validate the signature over the SDLP canonical
   envelope. The signer metadata MUST NOT alter the SDLP object or any
   SDLP-defined fields. Instead, it provides external information needed
   to evaluate the authenticity and trustworthiness of the signature.

   The following signer metadata fields are defined by this profile:

   *  signer: an identifier for the entity that produced the signature
      over the canonical envelope. The signer identifier MAY be a
      public key, certificate reference, or other cryptographically
      verifiable identity.

   *  signature: the signature computed over the exact canonical
      envelope bytes. The signature MUST be verifiable using the signer
      identifier.

   *  signature_algorithm: an identifier for the algorithm used to
      produce the signature. This profile does not constrain the choice
      of algorithm but requires that it be unambiguously represented.

   Trust-root pinning associates the signer with a trust anchor that a
   relying party uses to determine whether the signer is authorized to
   produce the referenced SDLP object. The following trust-root metadata
   fields are defined by this profile:

   *  trust_root: a reference to the trust anchor used to validate the
      signer. The trust_root MAY be a certificate, key identifier,
      transparency log root, or other verifiable trust anchor.

   *  trust_root_pin: a digest or other cryptographic reference that
      enables relying parties to confirm that the trust_root has not
      been substituted or altered.

   A relying party performs trust-root validation by confirming that:

   1.  The signature over the canonical envelope is valid under the
       signer identifier.

   2.  The signer identifier is authorized under the referenced
       trust_root.

   3.  The trust_root matches the trust_root_pin carried in the
       transition vector.

   If any of these checks fail, the relying party MUST set the
   binding_result to REFUSED, as defined in Section 6. If the signer or
   trust_root cannot be evaluated due to missing metadata or external
   dependencies, the relying party MUST set the binding_result to
   INDETERMINATE.

   Trust-root pinning does not modify SDLP semantics. It is an
   interoperability-layer mechanism that enables provenance and
   transparency systems to evaluate the authenticity of SDLP objects
   without altering the canonical envelope or digest rules defined by
   SDLP.

6.  Binding Result Vocabulary and Relying-Party Decisions

   SDLP defines the canonical envelope, identity, lineage, lifecycle
   state, timestamps, and digest computation rules for governed objects.
   SDLP does not define admission semantics or the conditions under
   which a relying party determines whether an object is acceptable
   within a trust domain. This section defines the binding_result
   vocabulary and relying-party decision semantics used in this
   interoperability profile.

   A binding_result expresses the outcome of an interoperability-layer
   validation of an SDLP canonical object. The binding_result does not
   modify the SDLP object and is not part of SDLP semantics. It is
   carried in the transition vector to enable provenance and
   transparency systems to communicate admission decisions.

   The binding_result vocabulary consists of three values:

   *  SATISFIED: The SDLP canonical envelope is valid, the signature is
      verifiable under the signer identifier, the signer is authorized
      under the referenced trust_root, and no BitDrop or lineage
      integrity violations are present. A relying party MAY admit the
      object.

   *  REFUSED: The SDLP canonical envelope is invalid, the signature is
      not verifiable under the signer identifier, the signer is not
      authorized under the referenced trust_root, or a BitDrop or
      lineage integrity violation is detected. A relying party MUST NOT
      admit the object.

   *  INDETERMINATE: The SDLP canonical envelope is valid, but the
      relying party cannot evaluate the signer or trust_root due to
      missing metadata, external dependencies, or unavailable trust
      anchors. A relying party MAY defer admission or apply local
      policy.

   A relying party determines the binding_result by performing the
   following checks:

   1.  SDLP canonical validation: The relying party verifies that the
       canonical envelope is well-formed, deterministic, and digest-
       correct according to SDLP Identity, Lineage, Lifecycle, and
       Object Format specifications.

   2.  Signature validation: The relying party verifies that the
       signature over the canonical envelope is valid under the signer
       identifier.

   3.  Trust-root validation: The relying party verifies that the signer
       identifier is authorized under the referenced trust_root and that
       the trust_root matches the trust_root_pin.

   If all checks succeed, the binding_result MUST be SATISFIED. If any
   check fails, the binding_result MUST be REFUSED. If the relying party
   cannot complete trust-root or signature validation due to missing or
   unavailable metadata, the binding_result MUST be INDETERMINATE.

   The binding_result is an interoperability-layer construct. It does
   not alter SDLP semantics and MUST NOT be included in the SDLP
   canonical envelope or digest computation. It is carried in the
   transition vector to enable provenance and transparency systems to
   communicate admission decisions without modifying SDLP-defined
   fields.

7.  Transition Vectors

   A transition vector is the interoperability-layer artifact that
   carries a canonical SDLP object together with the metadata required
   to evaluate ownership binding, trust-root authorization, and
   relying-party admission semantics. Transition vectors do not modify
   SDLP semantics; they compose SDLP-defined fields with interoperability
   metadata defined in this profile.

   A transition vector MUST contain the following SDLP-layer fields:

   *  DigitalID
   *  InstanceID
   *  Lineage
   *  Timestamp
   *  Body
   *  digest: the SHA-256 digest computed over the exact canonical
      envelope bytes.

   A transition vector MUST contain the following interoperability-layer
   fields:

   *  owner_binding_ref: an identifier for the binding event.
   *  signer: the identity of the entity that produced the signature.
   *  signature: the signature over the canonical envelope.
   *  signature_algorithm: the algorithm used to produce the signature.
   *  trust_root: a reference to the trust anchor used to validate the
      signer.
   *  trust_root_pin: a cryptographic reference to the trust_root.
   *  binding_result: a value from the vocabulary defined in Section 6.

   Transition vectors MAY contain additional metadata required by
   provenance or transparency systems, provided that such metadata does
   not alter SDLP semantics or the canonical envelope.

7.1.  Transition Vector Structure

   A transition vector is represented as a structured artifact containing
   both SDLP-layer and interoperability-layer fields. The following
   abstract structure is RECOMMENDED:

   SDLP-Layer Fields:
      DigitalID
      InstanceID
      Lineage
      Timestamp
      Body
      digest

   Interoperability-Layer Fields:
      owner_binding_ref
      signer
      signature
      signature_algorithm
      trust_root
      trust_root_pin
      binding_result

   The SDLP-layer fields MUST be identical to the canonical envelope
   defined in SDLP Identity, Lineage, Lifecycle, and Object Format
   specifications. The digest MUST be computed over the exact canonical
   envelope bytes, without whitespace or metadata additions.

   The interoperability-layer fields MUST NOT be included in the SDLP
   canonical envelope or digest computation.

7.2.  OwnershipBinding Transition Vector (Example)

   The following example illustrates an OwnershipBinding transition
   vector using the ExampleMovie fixture referenced in Section 1.

   SDLP-Layer Fields:
      DigitalID: dist123/cust456/prod789/ExampleMovie/dl001/2026-07-27T14:32:10
      InstanceID: 1
      Lineage: 1
      Timestamp: 2026-07-27T14:32:10
      Body: ExampleMovie
      digest: e753809f5081c2992ade71afa3202784fe8084566710a58f5d1f5012105f4d24

   Interoperability-Layer Fields:
      owner_binding_ref: ob-20260727-0001
      signer: <creator-public-key>
      signature: <signature-over-canonical-envelope>
      signature_algorithm: <algorithm-identifier>
      trust_root: <trust-anchor-reference>
      trust_root_pin: <digest-of-trust-anchor>
      binding_result: SATISFIED

   This transition vector represents an initial OwnershipBinding event
   for the canonical SDLP object. The SDLP-layer fields are unchanged
   from the canonical envelope. The interoperability-layer fields provide
   the metadata required for relying-party admission decisions.

7.3.  Negative OwnershipBinding Vectors

   Negative vectors MUST carry the same SDLP-layer fields and digest as
   the positive vector. The binding_result MUST reflect the relying-party
   decision:

   *  REFUSED: invalid signature, unauthorized signer, altered DigitalID,
      BitDrop, or non-canonical envelope.

   *  INDETERMINATE: signer or trust_root cannot be evaluated due to
      missing metadata or external dependencies.

   Negative vectors enable provenance and transparency systems to detect
   invalid SDLP lineage, altered identifiers, or canonical violations
   without ambiguity.

7.4.  Additional Transition Vectors

   This profile defines additional transition vectors for SDLP lifecycle
   events, including:

   *  Duplication
   *  Transformation
   *  OwnershipTransfer
   *  Distribution
   *  Playback
   *  Derivation

   These vectors follow the same structure as the OwnershipBinding
   example and will be specified in future revisions of this document.

8.  SCITT and EMILIA Composition Rules

   SDLP defines the canonical envelope, identity, lineage, lifecycle
   state, timestamps, and digest computation rules for governed objects.
   The interoperability profile defined in this document composes SDLP
   objects with ownership binding, trust-root pinning, and relying-party
   admission semantics. This section specifies how transition vectors
   produced by this profile are integrated with SCITT transparency
   systems and EMILIA provenance systems.

8.1.  Composition Model

   SCITT and EMILIA operate on structured provenance events that carry
   canonical object representations, signature metadata, trust anchors,
   and admission semantics. Transition vectors defined in Section 7
   provide these fields without modifying SDLP semantics.

   A transition vector is mapped into a SCITT or EMILIA event by
   carrying:

   *  The SDLP canonical envelope (DigitalID, InstanceID, Lineage,
      Timestamp, Body).

   *  The digest computed over the canonical envelope.

   *  Signature metadata (signer, signature, signature_algorithm).

   *  Trust-root metadata (trust_root, trust_root_pin).

   *  The binding_result value (SATISFIED, REFUSED, INDETERMINATE).

   SCITT and EMILIA do not alter SDLP semantics. They consume transition
   vectors as external provenance artifacts and apply their own
   transparency or admission policies.

8.2.  SCITT Composition

   SCITT transparency systems record signed statements about digital
   objects. A transition vector is mapped into a SCITT transparency
   receipt as follows:

   *  The SDLP canonical envelope is included as the object payload.

   *  The digest is included as the object hash.

   *  The signer and signature are included as the SCITT statement
      signature.

   *  The trust_root and trust_root_pin are included as SCITT trust
      metadata.

   *  The binding_result is included as an admission indicator.

   SCITT verifiers MUST evaluate the SDLP canonical envelope according
   to SDLP specifications. SCITT verifiers MUST NOT modify SDLP fields
   or recompute lineage. SCITT verifiers MAY apply local policy based on
   the binding_result value.

   Negative transition vectors (REFUSED or INDETERMINATE) MUST be
   recorded as SCITT receipts when submitted. This enables transparency
   systems to detect invalid SDLP lineage, altered DigitalID values,
   BitDrop conditions, or non-canonical envelopes.

8.3.  EMILIA Composition

   EMILIA provenance systems record lifecycle events for governed
   objects. A transition vector is mapped into an EMILIA event as
   follows:

   *  The SDLP canonical envelope is included as the event object.

   *  The digest is included as the event hash.

   *  The signer and signature are included as the event signature.

   *  The trust_root and trust_root_pin are included as provenance trust
      metadata.

   *  The binding_result is included as the event admission state.

   EMILIA verifiers MUST evaluate the SDLP canonical envelope according
   to SDLP specifications. EMILIA verifiers MUST NOT modify SDLP fields
   or recompute lineage. EMILIA verifiers MAY apply local policy based
   on the binding_result value.

   Negative transition vectors MUST be represented as EMILIA events
   carrying the same SDLP canonical envelope and digest as the positive
   event. This enables provenance systems to detect invalid SDLP lineage
   or canonical violations without ambiguity.

8.4.  BitDrop Propagation

   BitDrop conditions detected during SDLP canonical validation MUST be
   reflected in the binding_result value. SCITT and EMILIA systems MUST
   propagate BitDrop conditions without modification.

   A BitDrop condition MUST result in a binding_result of REFUSED.

   SCITT and EMILIA systems MAY apply additional local policy when
   encountering BitDrop conditions but MUST NOT alter SDLP semantics or
   canonical envelope fields.

8.5.  Interoperability Guarantees

   The composition rules defined in this section ensure that:

   *  SDLP semantics remain unchanged.
   *  Transition vectors carry all metadata required for SCITT and
      EMILIA.
   *  Negative vectors propagate without ambiguity.
   *  BitDrop conditions are consistently represented.
   *  Relying-party admission semantics are external to SDLP.

   These guarantees enable SDLP to function as a stable, canonical
   object protocol while supporting interoperable provenance and
   transparency systems.

9.  Security Considerations

   The interoperability profile defined in this document composes SDLP
   canonical objects with ownership binding, trust-root pinning, and
   relying-party admission semantics. This section describes the
   security considerations associated with this composition model.

9.1.  Canonical Encoding Integrity

   SDLP canonical validation ensures that governed objects are serialized
   deterministically and that the digest reflects the exact canonical
   envelope bytes. Any deviation from canonical encoding—including
   altered whitespace, reordered fields, truncated lineage, or modified
   DigitalID values—MUST result in a binding_result of REFUSED.

   Relying parties MUST NOT accept objects whose canonical envelopes
   fail SDLP validation. Accepting such objects would enable substitution
   attacks, lineage rewriting, or unauthorized object mutation.

9.2.  BitDrop Detection

   BitDrop conditions occur when lineage is truncated, rewritten, or
   otherwise altered in a way that violates SDLP lineage semantics.
   BitDrop MUST be treated as a security violation.

   A BitDrop condition MUST result in a binding_result of REFUSED.

   Relying parties MUST NOT attempt to repair or reinterpret lineage
   affected by BitDrop. Doing so would enable adversaries to conceal
   unauthorized object derivations or disrupt provenance chains.

9.3.  Signature Validation

   Transition vectors carry signatures over the SDLP canonical envelope.
   Relying parties MUST validate signatures using the signer identifier
   and signature_algorithm fields.

   Failure to validate the signature MUST result in a binding_result of
   REFUSED.

   Relying parties MUST NOT accept unsigned or partially signed objects.
   Accepting such objects would enable impersonation attacks or
   unauthorized object injection.

9.4.  Trust-Root Substitution and Pinning

   Trust-root pinning protects against substitution attacks in which an
   adversary replaces the trust anchor used to validate the signer.

   Relying parties MUST verify that the trust_root matches the
   trust_root_pin carried in the transition vector. A mismatch MUST
   result in a binding_result of REFUSED.

   Relying parties MUST NOT accept trust roots that cannot be validated
   or that are inconsistent with local policy. Failure to enforce trust-
   root pinning would enable unauthorized signers to masquerade as
   trusted entities.

9.5.  Replay and Substitution Attacks

   Because SDLP canonical envelopes include timestamps and lineage,
   replaying an object in a different lifecycle context may violate
   provenance expectations. Relying parties SHOULD verify that the
   timestamp and lineage are consistent with expected lifecycle
   semantics.

   Substitution attacks in which an adversary replaces the Body field
   while preserving DigitalID or lineage MUST be detected by digest
   validation. Any mismatch MUST result in a binding_result of REFUSED.

9.6.  Negative Vectors and Transparency

   Negative transition vectors (REFUSED or INDETERMINATE) MUST carry the
   same SDLP canonical envelope and digest as the corresponding positive
   vector. This requirement prevents adversaries from concealing invalid
   objects by altering canonical fields in negative reports.

   Transparency systems such as SCITT MUST record negative vectors
   without modification. Failure to record negative vectors would enable
   provenance gaps or concealment of invalid SDLP objects.

9.7.  Separation of SDLP and Interoperability Semantics

   SDLP does not define ownership binding, trust-root profiles, or
   admission semantics. These concepts are defined exclusively in the
   interoperability layer.

   Relying parties MUST NOT treat interoperability-layer metadata as
   part of the SDLP canonical envelope. Doing so would enable adversaries
   to influence digest computation or canonical validation by injecting
   external metadata.

   The separation of SDLP semantics from interoperability semantics is a
   critical security property of this profile.

9.8.  Local Policy Considerations

   Relying parties MAY apply local policy when interpreting
   INDETERMINATE results. However, local policy MUST NOT override SDLP
   canonical validation or trust-root pinning requirements.

   Local policy MAY restrict acceptable trust roots, signature
   algorithms, or signer identities, provided that such restrictions do
   not alter SDLP semantics or canonical envelope fields.

10.  IANA Considerations

   This document has no IANA actions.

   The SDLP interoperability profile defined in this document does not
   create new registries, modify existing registries, or require any
   assignments from IANA. All semantics defined in this document operate
   at the interoperability layer and do not introduce new protocol
   parameters requiring centralized coordination.

   Future revisions of this document MAY define registry structures for
   transition vector types, binding_result extensions, or trust-root
   metadata formats. Any such registries would be specified in a later
   version of this document and are out of scope for this initial
   revision.

11.  Normative References

   [SDLP-Identity]
              Norton, M., "Secured Digital Lifecycle Protocol (SDLP):
              Identity Specification", Work in Progress,
              draft-norton-sdlp-identity-02, July 2026.

   [SDLP-Lineage]
              Norton, M., "Secured Digital Lifecycle Protocol (SDLP):
              Lineage Specification", Work in Progress,
              draft-norton-sdlp-lineage-01, July 2026.

   [SDLP-Lifecycle]
              Norton, M., "Secured Digital Lifecycle Protocol (SDLP):
              Lifecycle Specification", Work in Progress,
              draft-norton-sdlp-lifecycle-02, July 2026.

   [SDLP-ObjFormat]
              Norton, M., "Secured Digital Lifecycle Protocol (SDLP):
              Object Format Specification", Work in Progress,
              draft-norton-sdlp-obj-format-01, July 2026.

   [RFC5280]
              Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List (CRL) Profile", RFC 5280, May 2008.

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

   [RFC8785]
              Bray, T., "JSON Canonicalization Scheme (JCS)", RFC 8785,
              June 2020.

   [RFC8949]
              Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 8949, December 2020.

12.  Informative References

   [SCITT]
              Barnes, R., "Supply Chain Integrity, Transparency, and
              Trust (SCITT) Architecture", Work in Progress,
              draft-ietf-scitt-architecture-00, 2026.

   [EMILIA]
              Schrock, I., "EMILIA Provenance Framework", Work in
              Progress, draft-schrock-emilia-architecture-00, 2026.

   [CAID]
              Schrock, I., "Canonical Artifact Identity (CAID)",
              Work in Progress, draft-schrock-caid-00, 2026.

   [AEC]
              Schrock, I., "Artifact Event Canonicalization (AEC)",
              Work in Progress, draft-schrock-aec-00, 2026.

   [AEB]
              Schrock, I., "Artifact Event Binding (AEB)",
              Work in Progress, draft-schrock-aeb-00, 2026.

   [SDLP-Overview]
              Norton, M., "Secured Digital Lifecycle Protocol (SDLP):
              Architectural Overview", Work in Progress,
              draft-norton-sdlp-overview-01, July 2026.

   [Transparency]
              Steele, O., "Transparency Systems and Verifiable Event
              Logs", Work in Progress, draft-steele-transparency-00,
              2025.

   [Provenance]
              Lefevre, S., "Digital Provenance Models and Trust
              Frameworks", Work in Progress,
              draft-lefevre-provenance-00, 2025.

13.  Author's Address

   M. Norton
   Independent
   El Mirage, Arizona, USA

   Email: mark433norton@gmail.com