SDLP Interoperability Profile for Ownership, Verification, and Provenance Evidence
draft-norton-sdlp-interop-profile-04

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

        SDLP Interoperability Profile for Ownership, Verification,
                         and Provenance Evidence
               draft-norton-sdlp-interop-profile-04

M. Norton
Independent Protocol Architect
El Mirage, Arizona, USA
Email: mark433norton@gmail.com
05 August 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-08 and draft-norton-sdlp-
   lifecycle-04:

      YYYY-MM-DDTHH:MM:SS

   Interoperability Profile-04 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:<effect-code>
          * PINNED_FAILURE:<failure-code>

       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-08 and draft-norton-sdlp-
   lifecycle-04:

      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)
              Architecture",
              draft-norton-sdlp-arch-03, 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-08,
              work in progress.

   [SDLP-ID]  Norton, M., "SDLP Identity",
              draft-norton-sdlp-identity-02,
              work in progress.

   [SDLP-LC]  Norton, M., "SDLP Lineage",
              draft-norton-sdlp-lineage-03,
              work in progress.

   [SDLP-SEC] Norton, M., "SDLP Security Architecture",
              draft-norton-sdlp-sec-arch-04,
              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.

Appendix A.  SDLP Fixture Bundle (Version 4)

   This appendix provides a reference to the SDLP Fixture Bundle used for
   interoperability testing of SDLP canonical envelopes, mutated
   candidate inputs, digest constructions, lineage mutations, lifecycle
   transitions, and negative-case evaluation semantics.

   The SDLP Fixture Bundle (Version 4) is published at:

      https://github.com/MightyRighty1/SDLP/releases/tag/v4

   Fixture Bundle v4 includes canonical and non-canonical test artifacts
   corresponding to the following SDLP drafts:

      * SDLP Object Format:
        draft-norton-sdlp-obj-format-08

      * SDLP Identity:
        draft-norton-sdlp-identity-02

      * SDLP Lineage:
        draft-norton-sdlp-lineage-03

      * SDLP Lifecycle:
        draft-norton-sdlp-lifecycle-04

      * SDLP Security Architecture:
        draft-norton-sdlp-sec-arch-04

      * SDLP Architecture:
        draft-norton-sdlp-arch-03

      * SDLP Overview:
        draft-norton-sdlp-overview-01

      * SDLP Physics Model:
        draft-norton-sdlp-phys-00

   The fixture bundle provides:

      * canonical SDLP envelopes for positive-case validation,
      * mutated candidate inputs for negative-case evaluation,
      * lineage mutation examples,
      * lifecycle transition examples,
      * digest mismatch cases,
      * signature-invalid cases,
      * authority-refused cases,
      * CAID projection mismatches,
      * AEC UNSATISFIED evidence cases,
      * AEB pinned failure outcomes.

   These artifacts are intended for use by provenance, transparency, and
   verification systems such as CAID, AEC, AEB, SCITT, and EMILIA. The
   fixture bundle does not modify SDLP canonical semantics; it provides
   reproducible test inputs for evaluating transition vectors produced
   under this interoperability profile.

13.  Revision History

   draft-norton-sdlp-interop-profile-04

      * Updated all SDLP references to current live versions:
        obj-format-08, identity-02, lineage-03, lifecycle-04,
        sec-arch-04, arch-03, overview-01, and phys-00.
      * Added Appendix A describing the SDLP Fixture Bundle (Version 4)
        and its relationship to canonical and mutated test artifacts.
      * Refined transition vector structure to align with updated SDLP
        canonical semantics and external verification pipelines.
      * Clarified negative-case handling, including pinned failure codes
        and mutated candidate input requirements.
      * Updated SCITT and EMILIA composition rules for consistency with
        current CAID, AEC, and AEB drafts.

   draft-norton-sdlp-interop-profile-03

      * Introduced multi-stage verification chain (SDLP canonical
        validation, CAID projection, AEC evidence evaluation, local
        authorization, and AEB execution).
      * Added trust-root pinning, signer metadata, and authority
        semantics.
      * Added detailed transition vector structure and binding
        requirements (VerifierID, TrustRootSnapshot, AuthorityPolicySnapshot,
        MappingProfileDigest, and execution boundaries).
      * Added SCITT and EMILIA composition model.

   draft-norton-sdlp-interop-profile-02

      * Added negative-case semantics, including mutated candidate
        inputs and pinned failure codes.
      * Added CAID projection equivalence rules.
      * Added AEC evidence result semantics (SATISFIED vs UNSATISFIED).
      * Added local authorization decision semantics (AUTHORIZED vs REFUSED).

   draft-norton-sdlp-interop-profile-01

      * Added canonical envelope handling and signature verification
        semantics.
      * Added initial trust-root and authority separation model.
      * Added early transition vector structure.

   draft-norton-sdlp-interop-profile-00

      * Initial draft defining the interoperability profile for SDLP
        external verification pipelines and provenance systems.

Author's Address

   M. Norton
   Independent Protocol Architect
   El Mirage, Arizona, USA
   Email: mark433norton@gmail.com