Internet-Draft M. Norton Intended status: Informational Independent Expires: 30 January 2027 30 July 2026 SDLP Interoperability Profile for Ownership, Verification, and Provenance Evidence draft-norton-sdlp-interop-profile-03 M. Norton Independent Protocol Architect El Mirage, Arizona, USA Email: mark433norton@gmail.com 30 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 external verification, typed authority evaluation, and provenance evidence semantics. It introduces a transition vector model that carries canonical SDLP envelopes together with CAID projections, AEC evidence results, local authorization decisions, and AEB execution outcomes, without altering SDLP’s core object semantics. The profile defines how SDLP objects participate in multi-stage verification pipelines and how mutated candidate inputs, negative cases, and authority constraints are represented. It also specifies composition rules for integrating SDLP with provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA, while preserving the separation of concerns between SDLP canonical semantics and ecosystem-specific admission and trust policies. 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, Signer Metadata, and Authority Semantics 18 6. Verification Chain and Evidence Results . . . . . . . . . . 22 7. Transition Vectors and Candidate Inputs . . . . . . . . . . 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. SDLP specifies deterministic serialization rules and validation semantics for these fields, but it does not define external verification pipelines, authority evaluation, provenance evidence requirements, or relying- party admission decisions. This interoperability profile defines how canonical SDLP objects are composed with external verification and provenance evidence systems without altering SDLP semantics. The profile introduces a transition vector model that carries the SDLP canonical envelope together with verification results from CAID, AEC, local authorization policy, and AEB execution outcomes. These results are expressed as separate, typed fields rather than a single admission value, preserving the multi-stage structure of provenance evaluation. The profile also defines how candidate inputs, mutated objects, and negative cases are represented. An invalid signature or unauthorized signer may be evaluated over an unchanged canonical envelope, while altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields require carrying the mutated candidate input and its expected failure. Authority evaluation is distinct from signature verification. A signature authenticates the signer, but does not establish that the signer is authorized to bind the named owner or trust domain. This profile introduces typed authority references and associated policy metadata to support explicit authorization semantics. Finally, this document specifies how transition vectors produced by this profile are composed with provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA. These systems consume transition vectors as external evidence artifacts and apply their own policies without modifying SDLP-defined fields or canonical envelope semantics. 2. SDLP Canonical Envelope (Imported Semantics) The Secured Digital Lifecycle Protocol (SDLP) defines a canonical envelope for governed digital objects. The envelope includes the DigitalID, lineage, lifecycle state, timestamps, digest fields, and associated metadata. SDLP specifies deterministic serialization rules for these fields and defines the conditions under which a canonical envelope is considered valid. This interoperability profile does not modify SDLP’s canonical semantics. All SDLP-defined fields, validation rules, and digest constructions are imported without change. A transition vector produced under this profile MUST carry either: * the exact canonical SDLP envelope, or * a mutated candidate input when evaluating negative cases involving altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields. Signature verification over the SDLP envelope authenticates the signer but does not establish authority to bind the named owner or trust domain. Authority evaluation is performed separately and is defined by this profile, not by SDLP. SDLP canonical validation is the first stage of the verification chain defined in Section 6. A transition vector MUST record whether the SDLP envelope is canonical, whether its digest matches the canonical preimage, and whether the signature suite and key material are valid for the envelope being evaluated. The Timestamp field carried within a canonical SDLP envelope or a mutated candidate input MUST follow the SDLP timestamp grammar defined in draft-norton-sdlp-obj-format-01 and draft-norton-sdlp- lifecycle-02: YYYY-MM-DDTHH:MM:SS Interoperability Profile-01 does not introduce timezone suffixes, fractional seconds, milliseconds, or RFC 3339 extensions. Any Timestamp value that deviates from the SDLP grammar MUST be treated as a canonicalization error during SDLP validation. Subsequent verification stages—CAID projection, AEC evidence evaluation, local authorization policy, and AEB execution outcome—are external to SDLP and are defined by this interoperability profile. 3. Interoperability Profile Model This interoperability profile defines how canonical SDLP objects are evaluated within external verification and provenance evidence systems. The profile does not modify SDLP’s canonical envelope, serialization rules, or validation semantics. Instead, it specifies how SDLP objects participate in a multi-stage verification pipeline and how the results of each stage are represented. A transition vector is the core artifact defined by this profile. A transition vector carries: * the canonical SDLP envelope or a mutated candidate input, * the signature suite and key material used to authenticate the signer, * the CAID projection of the submitted action, * the AEC evidence requirement and the computed AEC result, * the local authorization decision under a typed authority policy, * the AEB execution outcome for admitted actions. Each of these results is represented as a separate, typed field. The profile does not collapse these values into a single admission decision. This separation preserves the boundaries between SDLP canonical validation, CAID action identification, AEC evidence evaluation, local authorization policy, and AEB execution semantics. A transition vector may represent either a positive case or a negative case. Positive cases carry the canonical SDLP envelope and the expected results for each verification stage. Negative cases may carry either the canonical envelope (for invalid signatures or unauthorized signers) or a mutated candidate input (for altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields). Each negative case includes a pinned failure code describing the expected outcome. This profile also defines typed authority references and associated policy metadata. Signature verification authenticates the signer, but does not establish authority to bind the named owner or trust domain. Authority evaluation is performed separately and is expressed as a distinct field within the transition vector. Transition vectors produced under this profile are intended for consumption by provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA. These systems apply their own policies and admission rules without modifying SDLP-defined fields or canonical envelope semantics. 4. OwnershipBinding Event Semantics SDLP defines the DigitalID, lineage, lifecycle state, and canonical digest fields that identify and govern a digital object. SDLP does not define the conditions under which a signer is authorized to bind the named owner, nor does it define admission or execution semantics for submitted actions. These functions are external to SDLP and are specified by this interoperability profile. An OwnershipBinding event represents a submitted action in which a signer asserts that a digital object, identified by its DigitalID and canonical envelope, is owned, governed, or otherwise controlled under a specific trust domain. The event carries the canonical SDLP envelope, the signature suite and key material used to authenticate the signer, and the typed authority reference under which the signer claims binding rights. Signature verification authenticates the signer but does not establish authority. Authority evaluation is performed separately and is expressed as a distinct field within the transition vector. A typed authority reference identifies the enrollment, credential, or policy under which the signer may be authorized to bind the named owner or trust domain. The profile does not prescribe the content of authority policies, but requires that the policy be referenced explicitly and evaluated independently of signature verification. OwnershipBinding events participate in the multi-stage verification chain defined in Section 6. The SDLP canonical envelope is validated first, followed by CAID projection of the submitted action, AEC evidence evaluation, local authorization under the referenced authority policy, and AEB execution outcome. Each stage produces a separate, typed result recorded in the transition vector. Negative OwnershipBinding events may carry either the canonical SDLP envelope (for invalid signatures or unauthorized signers) or a mutated candidate input (for altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields). Each negative case includes a pinned failure code describing the expected outcome under the referenced authority policy and verification chain. 5. Trust-Root Pinning, Signer Metadata, and Authority Semantics SDLP defines the canonical envelope and the signature over that envelope, but it does not define trust-root selection, signer authority, or the conditions under which a signer may bind the named owner or trust domain. These functions are external to SDLP and are specified by this interoperability profile. Trust-root pinning identifies the key material, certificate, or enrollment record under which a submitted signature is evaluated. Pinning does not imply authority. A pinned trust root establishes the cryptographic identity of the signer, but does not determine whether the signer is authorized to perform the asserted action. Authority evaluation is performed separately and is expressed as a distinct field within the transition vector. Signer metadata includes the signature suite, key material, and any associated enrollment or credential information required to evaluate the authenticity of the submitted envelope. This profile does not prescribe specific signature suites or key formats, but requires that the suite and key material be recorded explicitly in the transition vector so that external systems can reproduce the verification results. Authority semantics define the conditions under which a signer may bind the named owner or trust domain. A typed authority reference identifies the enrollment, credential, or policy under which the signer claims binding rights. The profile does not define the content of authority policies, but requires that the referenced policy be evaluated independently of signature verification and trust-root pinning. Trust-root pinning, signer metadata, and authority evaluation participate in the multi-stage verification chain defined in Section 6. Signature verification authenticates the signer. CAID projection identifies the submitted action. AEC evidence evaluation determines whether the required evidence is satisfied. Local authorization evaluates the referenced authority policy. AEB execution determines the outcome for admitted actions. Each stage produces a separate, typed result recorded in the transition vector. Negative cases may arise from invalid signatures, unauthorized signers, mismatched authority policies, or mutated candidate inputs. Each negative case includes a pinned failure code describing the expected outcome under the referenced trust root and authority policy. 6. Verification Chain and Evidence Results This interoperability profile defines a multi-stage verification chain for evaluating submitted SDLP objects and OwnershipBinding events. Each stage produces a separate, typed result recorded in the transition vector. The profile does not collapse these values into a single admission decision. This separation preserves the boundaries between SDLP canonical validation, CAID action identification, AEC evidence evaluation, local authorization policy, and AEB execution semantics. Each verification-stage result MUST be bound to the producing verifier and its evaluation context. A transition vector MUST record: * VerifierID identifying the system that produced the result, * TrustRootSnapshot describing the key material and enrollment state under which signature verification was performed, * AuthorityPolicySnapshot describing the policy metadata used for local authorization, * MappingProfileDigest identifying the profile version used for CAID projection, * ExecutorBoundary, ProviderBoundary, and WitnessBoundary describing the execution context for AEB outcomes. These bindings ensure that verification results are reproducible by external systems and are not asserted without reference to the verifier, trust root, or policy context that produced them. The verification chain consists of the following stages: 1. SDLP Canonical Validation The submitted envelope is evaluated according to SDLP canonical rules. The transition vector records whether the envelope is canonical, whether its digest matches the canonical preimage, and whether the signature suite and key material are valid for the envelope being evaluated. Signature verification authenticates the signer but does not establish authority. SDLP canonical validation produces a typed result: * CANONICAL * NON_CANONICAL * SIGNATURE_INVALID SDLP canonical validation does not evaluate evidence, authority, or execution semantics. 2. CAID Projection The submitted action is projected into a Canonical Action Identifier (CAID) according to the rules defined in draft-schrock-canonical-action-identifier-01. The transition vector records the CAID value and the projection result: * EQUIVALENT_UNDER_PROFILE * NOT_EQUIVALENT * INDETERMINATE CAID projection identifies the submitted action but does not evaluate evidence or authority. 3. AEC Evidence Evaluation The Authorization Evidence Chain (AEC), defined in draft-schrock-ep-authorization-evidence-chain-04, specifies the evidence required for the submitted action. The transition vector records the required evidence and the computed AEC result: * SATISFIED * UNSATISFIED SATISFIED is an AEC evidence result, not an admission decision. A submitted artifact MUST NOT assert its own authoritative result; a production verifier computes these results. 4. Local Authorization Decision Local authorization evaluates the typed authority reference and associated policy metadata under which the signer claims binding rights. The transition vector records the local authorization decision: * AUTHORIZED * REFUSED Authority evaluation is independent of signature verification, trust-root pinning, CAID projection, and AEC evidence results. 5. AEB Execution Outcome The Action Evidence Boundary (AEB), defined in draft-schrock-action-evidence-boundary-00, specifies the execution semantics for admitted actions. The transition vector records the AEB execution outcome: * EXECUTED: * PINNED_FAILURE: AEB execution is performed only for admitted actions; negative cases record a pinned failure code instead. Each stage of the verification chain is evaluated independently. A failure at any stage does not prevent subsequent stages from being evaluated, except where evaluation is undefined (e.g., AEB execution for negative cases). This structure allows provenance and transparency systems to consume transition vectors as external evidence artifacts and apply their own policies without modifying SDLP-defined fields or canonical envelope semantics. Negative cases may arise from invalid signatures, unauthorized signers, mismatched CAID projections, UNSATISFIED evidence results, REFUSED authority decisions, or mutated candidate inputs. Each negative case includes a pinned failure code describing the expected outcome under the referenced trust root, authority policy, and verification chain. Negative cases MUST authenticate the mutated candidate input directly; the baseline envelope MUST NOT be used. 7. Transition Vectors and Candidate Inputs A transition vector is the core artifact defined by this interoperability profile. A transition vector carries the SDLP canonical envelope or a mutated candidate input together with the results of each stage of the verification chain defined in Section 6. Transition vectors do not modify SDLP semantics; they record external verification and authority results alongside the submitted object. A transition vector consists of the following components: * The canonical SDLP envelope, or a mutated candidate input when evaluating negative cases involving altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields. * The signature suite and key material used to authenticate the signer. Signature verification authenticates the signer but does not establish authority. * The CAID projection of the submitted action, including whether the projection matches the expected action for the submitted envelope. * The AEC evidence requirement and the computed AEC result (SATISFIED or UNSATISFIED). SATISFIED is an evidence result, not an admission decision. * The typed authority reference and associated policy metadata under which the signer claims binding rights, together with the local authorization decision (AUTHORIZED or REFUSED). * The AEB execution outcome for admitted actions, or a pinned failure code for negative cases. All Timestamp values carried within a canonical SDLP envelope or a mutated candidate input MUST follow the SDLP timestamp grammar defined in draft-norton-sdlp-obj-format-01 and draft-norton-sdlp- lifecycle-02: YYYY-MM-DDTHH:MM:SS Transition vectors MUST NOT introduce timezone suffixes, fractional seconds, milliseconds, or RFC 3339 extensions. Any Timestamp value that deviates from the SDLP grammar MUST be treated as a canonicalization error during SDLP validation and MUST cause the transition vector to record a pinned failure code for SDLP canonical validation. Each verification-stage result recorded in a transition vector MUST be bound to the producing verifier and its evaluation context. A transition vector MUST therefore include: * VerifierID identifying the system that produced the result, * TrustRootSnapshot describing the key material and enrollment state under which signature verification was performed, * AuthorityPolicySnapshot describing the policy metadata used for local authorization, * MappingProfileDigest identifying the profile version used for CAID projection, * ExecutorBoundary, ProviderBoundary, and WitnessBoundary describing the execution context for AEB outcomes. These bindings ensure that CAID projection, AEC evidence evaluation, local authorization decisions, and AEB execution outcomes are reproducible by external systems and are not asserted without reference to the verifier, trust root, or policy context that produced them. Transition vectors may represent either positive or negative cases. Positive cases carry the canonical SDLP envelope and the expected results for each verification stage. Negative cases may carry either the canonical envelope (for invalid signatures or unauthorized signers) or a mutated candidate input (for altered DigitalID values, lineage mutations, non-canonical preimages, or modified Body fields). Negative cases MUST include a pinned failure code describing the expected outcome under the referenced trust root, authority policy, and verification chain. Failure codes are not collapsed admission decisions; they identify the specific stage and condition under which the negative case is expected to fail. A complete transition vector includes: * exact canonical bytes or mutated candidate input, * digest construction and canonical preimage, * signature suite and key material, * typed trust-root and authority references, * CAID projection, * AEC evidence requirement and computed result, * local authorization decision, * AEB execution outcome or pinned failure code, * VerifierID, TrustRootSnapshot, AuthorityPolicySnapshot, MappingProfileDigest, ExecutorBoundary, ProviderBoundary, and WitnessBoundary. These fields allow provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA to consume transition vectors as external evidence artifacts and apply their own policies without modifying SDLP-defined fields or canonical envelope semantics. 8. SCITT and EMILIA Composition Rules This interoperability profile defines how transition vectors produced under Sections 6 and 7 are composed with provenance and transparency systems such as SCITT and EMILIA. These systems consume transition vectors as external evidence artifacts and apply their own policies without modifying SDLP-defined fields or canonical envelope semantics. SDLP defines the canonical envelope and the signature over that envelope. SCITT defines statement registration and receipt semantics. EMILIA defines the architecture, action identification, evidence requirements, and execution boundaries for submitted actions. These systems operate over transition vectors but do not alter SDLP’s canonical object model. SCITT receipts record registration of a statement, not its truth or admission. A SCITT receipt proves that a statement was registered under a transparency service, but does not establish that the submitted envelope is canonical, that the signer is authorized, that the required evidence is satisfied, or that the action is admitted. Invalid submissions MAY be rejected without receiving SCITT receipts. SCITT registration is not required for negative cases. EMILIA composition follows the boundaries defined in the EMILIA architecture (draft-schrock-ep-architecture-02). CAID projection identifies the submitted action according to draft-schrock-canonical-action-identifier-01. AEC evidence evaluation follows the rules defined in draft-schrock-ep-authorization-evidence- chain-04. AEB execution semantics follow the rules defined in draft-schrock-action-evidence-boundary-00. Each of these systems consumes the corresponding fields in the transition vector and applies its own policies without modifying SDLP-defined fields. Transition vectors provide the canonical SDLP envelope or mutated candidate input, signature suite and key material, CAID projection, AEC evidence requirement and result, local authorization decision, and AEB execution outcome or pinned failure code. SCITT and EMILIA systems evaluate these fields according to their own policies and trust models. The profile does not prescribe SCITT or EMILIA policy content; it defines the structure and semantics of the evidence artifacts consumed by those systems. SCITT and EMILIA composition preserves the separation of concerns between SDLP canonical semantics, external verification pipelines, authority evaluation, evidence requirements, and execution semantics. Transition vectors serve as the interoperability boundary between SDLP and these external systems. 9. Security Considerations This interoperability profile preserves SDLP’s canonical semantics and does not modify SDLP’s object model, digest construction, or signature rules. All security considerations defined by SDLP therefore apply directly to the canonical envelope carried within a transition vector. The profile introduces additional security considerations associated with external verification pipelines, authority evaluation, and provenance evidence systems. Signature verification authenticates the signer but does not establish authority. Trust-root pinning identifies the key material under which a signature is evaluated, but does not determine whether the signer is authorized to bind the named owner or trust domain. Authority evaluation is performed separately and must be implemented with care to avoid conflating authenticity with authorization. Mutated candidate inputs used for negative cases introduce additional risks. A mutated DigitalID, lineage field, non-canonical preimage, or modified Body field may be structurally valid but semantically incorrect. Systems consuming transition vectors MUST NOT treat mutated candidate inputs as canonical SDLP envelopes. Negative cases MUST include pinned failure codes to prevent misinterpretation of expected failures as successful evaluations. CAID projection, AEC evidence evaluation, and AEB execution semantics are external to SDLP and introduce their own security considerations. CAID projection identifies the submitted action but does not validate evidence or authority. AEC evidence results (SATISFIED or UNSATISFIED) are computed by production verifiers and MUST NOT be asserted by submitted artifacts. AEB execution semantics apply only to admitted actions; negative cases MUST NOT trigger execution. SCITT receipts record registration of statements, not their truth or admission. A SCITT receipt proves that a statement was registered under a transparency service, but does not establish that the submitted envelope is canonical, that the signer is authorized, that the required evidence is satisfied, or that the action is admitted. Invalid submissions MAY be rejected without receiving SCITT receipts. Transition vectors may contain sensitive metadata, including signer credentials, authority references, and evidence results. Systems consuming transition vectors MUST ensure that this information is handled according to applicable privacy, confidentiality, and provenance requirements. The separation of SDLP canonical semantics from external verification pipelines is a core security property of this profile. Systems MUST NOT modify SDLP-defined fields or canonical envelope semantics when evaluating transition vectors. External verification results MUST be recorded as separate, typed fields to prevent conflation of canonical object validity with admission or execution semantics. 10. IANA Considerations This document has no IANA actions. 11. Normative References [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020. [SDLP] Norton, M., "Secured Digital Lifecycle Protocol (SDLP)", draft-norton-sdlp-arch-01, work in progress. [CAID] Schrock, I., "Canonical Action Identifier (CAID)", draft-schrock-canonical-action-identifier-01, work in progress. [AEC] Schrock, I., "Authorization Evidence Chain (AEC)", draft-schrock-ep-authorization-evidence-chain-04, work in progress. [AEB] Schrock, I., "Action Evidence Boundary (AEB)", draft-schrock-action-evidence-boundary-00, work in progress. [EMILIA] Schrock, I., "EMILIA Architecture", draft-schrock-ep-architecture-02, work in progress. [SCITT] Lundblade, L., et al., "Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture", draft-ietf-scitt-architecture-13, work in progress. 12. Informative References [SDLP-OBJ] Norton, M., "SDLP Object Format", draft-norton-sdlp-obj-format-01, work in progress. [SDLP-ID] Norton, M., "SDLP Identity and Lineage", draft-norton-sdlp-identity-01, work in progress. [SDLP-LC] Norton, M., "SDLP Lifecycle Semantics", draft-norton-sdlp-lineage-01, work in progress. [SDLP-SEC] Norton, M., "SDLP Security Architecture", draft-norton-sdlp-sec-arch-01, work in progress. [SCITT-REG] Birkholz, H., et al., "SCITT Entity Attestation Token (EAT) Profiles and Registration Semantics", draft-ietf-scitt-eat-profile-09, work in progress. [EMILIA-REQ] Schrock, I., "EMILIA Requirements and Policy Model", draft-schrock-ep-requirements-00, work in progress. [EMILIA-TRANS] Schrock, I., "EMILIA Transparency and Evidence Model", draft-schrock-ep-transparency-00, work in progress. [CBOR-META] Bormann, C., "CBOR Tag Registries and Metadata", draft-bormann-cbor-metadata-02, work in progress. Author's Address M. Norton Independent Protocol Architect El Mirage, Arizona, USA Email: mark433norton@gmail.com