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: signature: signature_algorithm: trust_root: trust_root_pin: 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