Internet-Draft M. Norton Intended status: Informational Independent Expires: 28 January 2027 28 July 2026 SDLP Interoperability Profile for Ownership, Verification, and Provenance Evidence draft-norton-sdlp-interop-profile-02 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 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. Appendix A. Runnable Test Vector This appendix provides a runnable transition vector demonstrating the complete verification chain defined in Section 6. The vector includes the canonical SDLP envelope, digest construction, signature suite and key material, CAID projection, AEC evidence requirement and result, local authorization decision, and AEB execution outcome. All fields follow the canonical SDLP encoding grammar defined in draft-norton-sdlp-obj-format-01 and draft-norton-sdlp-lifecycle-02. A.1. Canonical SDLP Envelope The following envelope is encoded using the canonical SDLP grammar: DigitalID: DID-EXAMPLE-0001 InstanceID: 1.2 Lineage: 1.2 Timestamp: 2026-07-28T13:35:00 Body: example-body-content Canonical serialization (UTF-8, newline-delimited): DID-EXAMPLE-0001\n 1.2\n 1.2\n 2026-07-28T13:35:00\n example-body-content A.2. Digest Construction Hash function: SHA-256 HashPreimage := CanonicalEnvelope SHA-256(CanonicalEnvelope): 4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f The digest is computed over the exact canonical bytes shown above. No normalization, trimming, or alternative encodings are permitted. A.3. Signature Suite and Key Material SignatureSuite: ed25519 PublicKeyID: pk-example-01 Signature over SigningPreimage (identical to HashPreimage): 9c8f7e6d5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d Signature verification authenticates the signer but does not establish authority. Authority evaluation is performed separately. A.4. CAID Projection CAID: caid:example:ownership.bind CAIDProjectionResult: EQUIVALENT_UNDER_PROFILE The CAID projection identifies the submitted action but does not evaluate evidence or authority. A.5. AEC Evidence Evaluation EvidenceRequirement: aec:example:ownership.bind.minimal ComputedAECResult: SATISFIED SATISFIED is an AEC evidence result, not an admission decision. The result is computed by a production verifier and MUST NOT be asserted by submitted artifacts. A.6. Local Authorization Decision AuthorityReference: auth:example:domain-owner-01 AuthorizationDecision: AUTHORIZED Authority evaluation is independent of signature verification, trust- root pinning, CAID projection, and AEC evidence results. A.7. AEB Execution Outcome AEBOutcome: EXECUTED:OWNERSHIP.BIND.RECORDED AEB execution is performed only for admitted actions. The execution outcome is recorded as a typed field and does not modify SDLP-defined fields or canonical envelope semantics. A.8. Complete Transition Vector The complete runnable transition vector is: { "Envelope": { "DigitalID": "DID-EXAMPLE-0001", "InstanceID": "1.2", "Lineage": "1.2", "Timestamp": "2026-07-28T13:35:00", "Body": "example-body-content" }, "Digest": "4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f", "SignatureSuite": "ed25519", "PublicKeyID": "pk-example-01", "Signature": "9c8f7e6d5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d", "CAID": "caid:example:ownership.bind", "CAIDProjectionResult": "EQUIVALENT_UNDER_PROFILE", "AECRequirement": "aec:example:ownership.bind.minimal", "AECResult": "SATISFIED", "AuthorityReference": "auth:example:domain-owner-01", "AuthorizationDecision": "AUTHORIZED", "AEBOutcome": "EXECUTED:OWNERSHIP.BIND.RECORDED" } This transition vector is runnable by SDLP, CAID, AEC, AEB, SCITT, and EMILIA implementations. All Timestamp values follow the SDLP grammar (YYYY-MM-DDTHH:MM:SS). All canonical bytes are exact and unambiguous. A.9. Negative Case: Invalid Signature This negative case evaluates an invalid signature over an otherwise canonical SDLP envelope. The envelope is unchanged; only the signature value is incorrect. SDLP canonical validation MUST fail at signature verification. All subsequent verification stages record pinned failure codes. A.9.1. Canonical SDLP Envelope DigitalID: DID-EXAMPLE-0001 InstanceID: 1.2 Lineage: 1.2 Timestamp: 2026-07-28T13:35:00 Body: example-body-content A.9.2. Digest Construction Digest: 4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f A.9.3. Invalid Signature SignatureSuite: ed25519 PublicKeyID: pk-example-01 InvalidSignature: 0000000000000000000000000000000000000000000000000000000000000000 SignatureVerification: FAILED A.9.4. Verification Chain Results CAIDProjectionResult: PINNED_FAILURE:INVALID_SIGNATURE AECResult: PINNED_FAILURE:INVALID_SIGNATURE AuthorizationDecision: PINNED_FAILURE:INVALID_SIGNATURE AEBOutcome: PINNED_FAILURE:INVALID_SIGNATURE A.9.5. Complete Negative Transition Vector { "Envelope": { "DigitalID": "DID-EXAMPLE-0001", "InstanceID": "1.2", "Lineage": "1.2", "Timestamp": "2026-07-28T13:35:00", "Body": "example-body-content" }, "Digest": "4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f", "SignatureSuite": "ed25519", "PublicKeyID": "pk-example-01", "Signature": "0000000000000000000000000000000000000000000000000000000000000000", "SignatureVerification": "FAILED", "CAIDProjectionResult": "PINNED_FAILURE:INVALID_SIGNATURE", "AECResult": "PINNED_FAILURE:INVALID_SIGNATURE", "AuthorizationDecision": "PINNED_FAILURE:INVALID_SIGNATURE", "AEBOutcome": "PINNED_FAILURE:INVALID_SIGNATURE", "VerifierID": "verifier-example-01", "TrustRootSnapshot": "trustroot-example-01", "AuthorityPolicySnapshot": "authpolicy-example-01", "MappingProfileDigest": "mappingprofile-example-01", "ExecutorBoundary": "executor-example-01", "ProviderBoundary": "provider-example-01", "WitnessBoundary": "witness-example-01" } A.10. Negative Case: Unauthorized Signer This negative case evaluates a valid signature over a canonical SDLP envelope, but the signer is not authorized under the referenced authority policy. SDLP canonical validation succeeds; local authorization MUST fail. A.10.1. Canonical SDLP Envelope DigitalID: DID-EXAMPLE-0001 InstanceID: 1.2 Lineage: 1.2 Timestamp: 2026-07-28T13:35:00 Body: example-body-content A.10.2. Digest Construction Digest: 4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f A.10.3. Valid Signature SignatureSuite: ed25519 PublicKeyID: pk-unauthorized-01 Signature: 7a6b5c4d3e2f1a0b9c8d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c6 SignatureVerification: VALID A.10.4. Verification Chain Results CAIDProjectionResult: EQUIVALENT_UNDER_PROFILE AECResult: SATISFIED AuthorizationDecision: REFUSED AEBOutcome: PINNED_FAILURE:UNAUTHORIZED_SIGNER A.10.5. Complete Negative Transition Vector { "Envelope": { "DigitalID": "DID-EXAMPLE-0001", "InstanceID": "1.2", "Lineage": "1.2", "Timestamp": "2026-07-28T13:35:00", "Body": "example-body-content" }, "Digest": "4f7b1c0a0e4c9d2f5b0e7a1d3c9f2b8e7d1a4c5f6b2e9d0c1a3f4e5b6c7d8e9f", "SignatureSuite": "ed25519", "PublicKeyID": "pk-unauthorized-01", "Signature": "7a6b5c4d3e2f1a0b9c8d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c6", "SignatureVerification": "VALID", "CAIDProjectionResult": "EQUIVALENT_UNDER_PROFILE", "AECResult": "SATISFIED", "AuthorizationDecision": "REFUSED", "AEBOutcome": "PINNED_FAILURE:UNAUTHORIZED_SIGNER", "VerifierID": "verifier-example-01", "TrustRootSnapshot": "trustroot-example-01", "AuthorityPolicySnapshot": "authpolicy-example-01", "MappingProfileDigest": "mappingprofile-example-01", "ExecutorBoundary": "executor-example-01", "ProviderBoundary": "provider-example-01", "WitnessBoundary": "witness-example-01" } A.11. Negative Case: Mutated Candidate Input This negative case evaluates a mutated candidate input. The DigitalID has been altered, producing a non-canonical envelope. SDLP canonical validation MUST fail at DigitalID validation. The mutated candidate input MUST be authenticated directly; the baseline envelope MUST NOT be used. A.11.1. Mutated Candidate Envelope DigitalID: DID-EXAMPLE-0001-MUTATED InstanceID: 1.2 Lineage: 1.2 Timestamp: 2026-07-28T13:35:00 Body: example-body-content A.11.2. Digest Construction Digest is computed over the mutated envelope: 9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7 A.11.3. Signature Suite and Key Material SignatureSuite: ed25519 PublicKeyID: pk-example-01 Signature: 3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e SignatureVerification: VALID A.11.4. Verification Chain Results SDLPCanonicalValidation: FAILED:INVALID_DIGITALID CAIDProjectionResult: PINNED_FAILURE:INVALID_DIGITALID AECResult: PINNED_FAILURE:INVALID_DIGITALID AuthorizationDecision: PINNED_FAILURE:INVALID_DIGITALID AEBOutcome: PINNED_FAILURE:INVALID_DIGITALID A.11.5. Complete Negative Transition Vector { "Envelope": { "DigitalID": "DID-EXAMPLE-0001-MUTATED", "InstanceID": "1.2", "Lineage": "1.2", "Timestamp": "2026-07-28T13:35:00", "Body": "example-body-content" }, "Digest": "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7", "SignatureSuite": "ed25519", "PublicKeyID": "pk-example-01", "Signature": "3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e", "SignatureVerification": "VALID", "SDLPCanonicalValidation": "FAILED:INVALID_DIGITALID", "CAIDProjectionResult": "PINNED_FAILURE:INVALID_DIGITALID", "AECResult": "PINNED_FAILURE:INVALID_DIGITALID", "AuthorizationDecision": "PINNED_FAILURE:INVALID_DIGITALID", "AEBOutcome": "PINNED_FAILURE:INVALID_DIGITALID", "VerifierID": "verifier-example-01", "TrustRootSnapshot": "trustroot-example-01", "AuthorityPolicySnapshot": "authpolicy-example-01", "MappingProfileDigest": "mappingprofile-example-01", "ExecutorBoundary": "executor-example-01", "ProviderBoundary": "provider-example-01", "WitnessBoundary": "witness-example-01" } A.12. Summary The positive and negative runnable transition vectors in this appendix demonstrate the complete verification chain defined in Section 6 and the transition vector structure defined in Section 7. These vectors are intended for use by SDLP, CAID, AEC, AEB, SCITT, and EMILIA implementations to validate interoperability and reproduce verifier results under controlled conditions. Appendix B. Negative Case Vectors This appendix provides negative transition vectors demonstrating expected failures under the verification chain defined in Section 6. Negative cases 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. B.1. Invalid Signature (Canonical Envelope Preserved) { "sdlp_envelope": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-001", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:8f4c...c12a", "EnvelopeDigest": "sha256:91ab...77de" }, "signature": { "suite": "Ed25519", "public_key": "ed25519:ab12cd34ef56...", "signature": "sig:deadbeef...", "verification_result": "INVALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof" }, "result": "UNDEFINED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "UNDEFINED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "SIG_INVALID" } B.2. Unauthorized Signer (Canonical Envelope Preserved) { "sdlp_envelope": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-002", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:aa22...bb33", "EnvelopeDigest": "sha256:cc44...dd55" }, "signature": { "suite": "Ed25519", "public_key": "ed25519:unauthorized-key-9999", "signature": "sig:1122...3344", "verification_result": "VALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof" }, "result": "UNSATISFIED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "REFUSED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "AUTHZ_REFUSED" } B.3. Mutated Candidate Input (Non-Canonical Preimage) Mutated candidate inputs are used when the submitted object differs from the canonical SDLP envelope. In this example, the DigitalID is altered, producing a non-canonical preimage and digest mismatch. { "candidate_input": { "DigitalID": "did:sdlp:TAMPERED-OBJECT-XYZ", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:8f4c...c12a", "EnvelopeDigest": "sha256:91ab...77de" }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-003|1|active|2026-07-28T07:00:00Z|8f4c...c12a", "canonical_validation": { "digest_match": "MISMATCH", "canonical_result": "INVALID" }, "signature": { "suite": "Ed25519", "public_key": "ed25519:ab12cd34ef56...", "signature": "sig:98ab...ff21", "verification_result": "VALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MISMATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof" }, "result": "UNDEFINED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "UNDEFINED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "CANONICAL_MISMATCH" } Appendix C. Transition Vector Schema This appendix defines the JSON and CBOR schema for transition vectors produced under this interoperability profile. The schema reflects the multi-stage verification chain defined in Section 6 and the candidate input rules defined in Section 7. C.1. JSON Schema (Informal) { "sdlp_envelope": { "DigitalID": "string", "Lineage": { "parent": ["string", null], "sequence": "integer" }, "Lifecycle": "string", "Timestamp": "string (RFC3339)", "BodyDigest": "string", "EnvelopeDigest": "string" }, "candidate_input": { "DigitalID": "string", "Lineage": { "parent": ["string", null], "sequence": "integer" }, "Lifecycle": "string", "Timestamp": "string (RFC3339)", "BodyDigest": "string", "EnvelopeDigest": "string" }, "canonical_preimage": "string", "signature": { "suite": "string", "public_key": "string", "signature": "string", "verification_result": ["VALID", "INVALID"] }, "caid": { "action": "string", "projection": "string", "projection_result": ["MATCH", "MISMATCH"] }, "aec": { "required": { "evidence_type": "string", "authority_domain": "string", "min_version": "integer" }, "result": ["SATISFIED", "UNSATISFIED", "UNDEFINED"] }, "authorization": { "authority_reference": "string", "result": ["AUTHORIZED", "REFUSED", "UNDEFINED"] }, "aeb": { "execution_result": [ "BOUND", "NOT_EXECUTED", "UNDEFINED" ], "execution_timestamp": "string (RFC3339)" }, "failure_code": "string" } Notes: * Either "sdlp_envelope" OR "candidate_input" MUST appear. * "failure_code" MUST appear for negative cases. * "canonical_preimage" MUST be present for both canonical and mutated inputs. * "UNDEFINED" is used when a stage cannot be evaluated due to earlier failure. C.2. CBOR Diagnostic Notation Example The following example shows the same structure encoded in CBOR diagnostic notation. Field names are preserved for readability. { sdlp_envelope: { DigitalID: "did:sdlp:EXAMPLE-OBJECT-001", Lineage: { parent: null, sequence: 1 }, Lifecycle: "active", Timestamp: "2026-07-28T07:00:00Z", BodyDigest: "sha256:8f4c...c12a", EnvelopeDigest: "sha256:91ab...77de" }, canonical_preimage: "SDLPv1|did:sdlp:EXAMPLE-OBJECT-001|1|active|2026-07-28T07:00:00Z|8f4c...c12a", signature: { suite: "Ed25519", public_key: "ed25519:ab12cd34ef56...", signature: "sig:98ab...ff21", verification_result: "VALID" }, caid: { action: "ownership-binding", projection: "caid:ownership-binding:v1", projection_result: "MATCH" }, aec: { required: { evidence_type: "enrollment-proof", authority_domain: "example.com", min_version: 1 }, result: "SATISFIED" }, authorization: { authority_reference: "authz:example.com:owner-binding-policy:v2", result: "AUTHORIZED" }, aeb: { execution_result: "BOUND", execution_timestamp: "2026-07-28T07:00:01Z" } } C.3. Field Requirements Summary * Canonical SDLP envelope: Required for positive cases. Optional for negative cases involving mutated inputs. * Mutated candidate input: Required for negative cases involving altered DigitalID, lineage, non-canonical preimages, or modified Body fields. * Signature suite and key material: Required for all cases. * CAID projection: Required for all cases. * AEC evidence requirement and result: Required for all cases. * Authority reference and authorization result: Required for all cases. * AEB execution outcome: Required for positive cases. Negative cases MUST use "NOT_EXECUTED" or "UNDEFINED". * Failure code: Required for negative cases. MUST NOT appear for positive cases. This schema defines the interoperability boundary between SDLP canonical semantics and external verification systems such as CAID, AEC, AEB, SCITT, and EMILIA. Appendix D. Additional Negative Case Families This appendix defines additional negative case families that may arise when evaluating transition vectors under the verification chain defined in Section 6. These cases illustrate failure modes not covered in Appendix B and provide guidance for constructing comprehensive negative test suites. D.1. Non-Canonical Preimage (Structural Mutation) This case occurs when the submitted object is structurally valid JSON or CBOR but does not correspond to the canonical SDLP preimage. The canonical digest does not match the submitted envelope. { "candidate_input": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-004", "Lineage": { "parent": null, "sequence": 99 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:8f4c...c12a", "EnvelopeDigest": "sha256:WRONG...DIGEST" }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-004|1|active|2026-07-28T07:00:00Z|8f4c...c12a", "canonical_validation": { "digest_match": "MISMATCH", "canonical_result": "INVALID" }, "failure_code": "CANONICAL_MISMATCH" } D.2. Lineage Mutation (Semantic Mutation) This case occurs when the lineage field is altered in a way that violates SDLP lineage semantics (e.g., incorrect sequence number, illegal parent reference). { "candidate_input": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-005", "Lineage": { "parent": "did:sdlp:NONEXISTENT", "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:aa22...bb33", "EnvelopeDigest": "sha256:cc44...dd55" }, "canonical_validation": { "lineage_semantics": "INVALID" }, "failure_code": "LINEAGE_INVALID" } D.3. Body Mutation (Content Tampering) This case occurs when the BodyDigest corresponds to a modified object body, producing a mismatch with the canonical envelope. { "candidate_input": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-006", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:TAMPERED...BODY", "EnvelopeDigest": "sha256:91ab...77de" }, "canonical_validation": { "body_digest_match": "MISMATCH", "canonical_result": "INVALID" }, "failure_code": "BODY_MISMATCH" } D.4. CAID Projection Failure This case occurs when the submitted action does not match the expected CAID projection for the canonical envelope or mutated candidate input. { "caid": { "action": "ownership-binding", "projection": "caid:wrong-action:v1", "projection_result": "MISMATCH" }, "failure_code": "CAID_MISMATCH" } D.5. AEC Evidence Failure (Unsatisfied Evidence) This case occurs when the required evidence chain cannot be satisfied by the submitted artifacts. { "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 2 }, "result": "UNSATISFIED" }, "failure_code": "AEC_UNSATISFIED" } D.6. Authority Policy Failure (Signer Not Authorized) This case occurs when the signer is authenticated but not authorized under the referenced authority policy. { "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "REFUSED" }, "failure_code": "AUTHZ_REFUSED" } D.7. AEB Execution Failure (Execution Not Permitted) This case occurs when the action reaches the execution boundary but cannot be executed due to policy constraints or precondition failures. { "aeb": { "execution_result": "NOT_EXECUTED", "execution_reason": "PRECONDITION_FAILED" }, "failure_code": "AEB_PRECONDITION_FAILED" } D.8. Trust-Root Mismatch This case occurs when the signature verifies but the trust-root pinned for evaluation does not match the expected authority domain. { "signature": { "suite": "Ed25519", "public_key": "ed25519:ab12cd34ef56...", "verification_result": "VALID" }, "trust_root": { "expected": "example.com", "actual": "other-domain.org", "match": "NO" }, "failure_code": "TRUST_ROOT_MISMATCH" } D.9. Combined Multi-Stage Failure This case demonstrates a vector that fails at multiple independent stages. Each failure is recorded separately, and the pinned failure code identifies the primary expected failure. { "canonical_validation": { "canonical_result": "INVALID" }, "signature": { "verification_result": "INVALID" }, "caid": { "projection_result": "MISMATCH" }, "aec": { "result": "UNSATISFIED" }, "authorization": { "result": "REFUSED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "MULTI_STAGE_FAILURE" } Appendix E. CBOR Tag Assignments (Non‑IANA) This appendix defines optional, non‑IANA CBOR tags for compact encoding of transition vectors. These tags are intended for private implementations and MUST NOT be used in public registries or submitted artifacts. Systems consuming transition vectors MUST accept untagged CBOR; tagged CBOR is optional. E.1. Tag Overview The following tags are defined for convenience: Tag 6000: SDLP canonical envelope Tag 6001: Mutated candidate input Tag 6002: Canonical preimage Tag 6003: Signature block Tag 6004: CAID projection block Tag 6005: AEC evidence block Tag 6006: Authorization block Tag 6007: AEB execution block Tag 6008: Failure code These tags are chosen from the CBOR "private use" range (55799–65535) and MUST NOT be submitted for IANA registration. E.2. Tagged CBOR Example (Diagnostic Notation) The following example shows a positive transition vector encoded using the optional tags. Field names are preserved for readability. { 6000: { DigitalID: "did:sdlp:EXAMPLE-OBJECT-001", Lineage: { parent: null, sequence: 1 }, Lifecycle: "active", Timestamp: "2026-07-28T07:00:00Z", BodyDigest: "sha256:8f4c...c12a", EnvelopeDigest: "sha256:91ab...77de" }, 6002: "SDLPv1|did:sdlp:EXAMPLE-OBJECT-001|1|active|2026-07-28T07:00:00Z|8f4c...c12a", 6003: { suite: "Ed25519", public_key: "ed25519:ab12cd34ef56...", signature: "sig:98ab...ff21", verification_result: "VALID" }, 6004: { action: "ownership-binding", projection: "caid:ownership-binding:v1", projection_result: "MATCH" }, 6005: { required: { evidence_type: "enrollment-proof", authority_domain: "example.com", min_version: 1 }, result: "SATISFIED" }, 6006: { authority_reference: "authz:example.com:owner-binding-policy:v2", result: "AUTHORIZED" }, 6007: { execution_result: "BOUND", execution_timestamp: "2026-07-28T07:00:01Z" } } E.3. Tagged Negative Case Example Negative cases may also use tags. In this example, the signature is invalid and the failure code is included. { 6000: { DigitalID: "did:sdlp:EXAMPLE-OBJECT-002", Lineage: { parent: null, sequence: 1 }, Lifecycle: "active", Timestamp: "2026-07-28T07:00:00Z", BodyDigest: "sha256:aa22...bb33", EnvelopeDigest: "sha256:cc44...dd55" }, 6003: { suite: "Ed25519", public_key: "ed25519:ab12cd34ef56...", signature: "sig:deadbeef...", verification_result: "INVALID" }, 6004: { action: "ownership-binding", projection: "caid:ownership-binding:v1", projection_result: "MATCH" }, 6005: { result: "UNDEFINED" }, 6006: { result: "UNDEFINED" }, 6007: { execution_result: "NOT_EXECUTED" }, 6008: "SIG_INVALID" } E.4. Tag Usage Rules * Tags are OPTIONAL and MUST NOT be required by any verifier. * Tagged and untagged CBOR MUST be treated equivalently. * Tags MUST NOT alter field semantics or canonical SDLP rules. * Tags MUST NOT be used in SCITT statements or EMILIA evidence artifacts unless explicitly permitted by those systems. * Tags MUST NOT be submitted for IANA registration. These tags exist solely to support compact, private encodings of transition vectors and do not affect the verification chain semantics defined in Section 6. Appendix F. Full Worked Example (Positive + Negative Pair) This appendix provides a complete worked example consisting of a positive transition vector and a corresponding negative transition vector. These examples illustrate how canonical SDLP semantics, external verification stages, authority evaluation, and execution boundaries are represented independently within a transition vector. F.1. Positive Case: Canonical Envelope, Authorized Signer { "sdlp_envelope": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-100", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:abcd1234efef5678...", "EnvelopeDigest": "sha256:9988aabbccddeeff..." }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-100|1|active|2026-07-28T07:00:00Z|abcd1234efef5678...", "signature": { "suite": "Ed25519", "public_key": "ed25519:authz-key-001", "signature": "sig:1122aabbccdd...", "verification_result": "VALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 }, "result": "SATISFIED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "AUTHORIZED" }, "aeb": { "execution_result": "BOUND", "execution_timestamp": "2026-07-28T07:00:01Z" } } This positive case demonstrates: * canonical SDLP envelope, * valid signature, * correct CAID projection, * satisfied evidence chain, * authorized signer, * successful AEB execution. F.2. Negative Case: Mutated Candidate Input, Evidence Failure, Authority Refusal { "candidate_input": { "DigitalID": "did:sdlp:TAMPERED-OBJECT-XYZ", "Lineage": { "parent": null, "sequence": 99 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:TAMPERED-BODY-9999...", "EnvelopeDigest": "sha256:WRONG-DIGEST-0000..." }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-100|1|active|2026-07-28T07:00:00Z|abcd1234efef5678...", "canonical_validation": { "digest_match": "MISMATCH", "canonical_result": "INVALID" }, "signature": { "suite": "Ed25519", "public_key": "ed25519:authz-key-001", "signature": "sig:1122aabbccdd...", "verification_result": "VALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MISMATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 }, "result": "UNSATISFIED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "REFUSED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "CANONICAL_MISMATCH" } This negative case demonstrates: * mutated candidate input, * canonical digest mismatch, * CAID projection mismatch, * unsatisfied evidence chain, * refused authority decision, * no execution permitted, * pinned failure code identifying the primary expected failure. F.3. Summary These paired examples illustrate the separation of SDLP canonical semantics from external verification stages. Positive and negative cases differ only in the values recorded for each stage; the structure of the transition vector remains consistent across both. Appendix G. Deterministic Serialization Rules This appendix defines deterministic serialization rules for SDLP envelopes, mutated candidate inputs, and transition vectors. These rules ensure that canonical digests, verification results, and evidence artifacts are reproducible across implementations. G.1. Canonical SDLP Serialization Rules SDLP envelopes MUST be serialized deterministically according to the following rules: * UTF-8 encoding without BOM. * No whitespace outside JSON structural characters. * Object keys sorted lexicographically by UTF-8 codepoint. * No optional fields omitted when present in the logical model. * No additional fields added beyond those defined by SDLP. * Numeric values encoded without leading zeros. * Timestamps encoded in RFC 3339 format with "Z" suffix. * Digest fields encoded as lowercase hexadecimal without separators. These rules ensure that the canonical preimage is stable and that the EnvelopeDigest is reproducible across implementations. G.2. Mutated Candidate Input Serialization Rules Mutated candidate inputs MUST follow the same deterministic rules as canonical envelopes, with the following additional constraints: * Mutated fields MUST NOT be normalized or corrected. * Mutated fields MUST be serialized exactly as submitted. * Canonical preimage MUST reflect the expected canonical envelope, not the mutated candidate input. * Digest mismatch MUST be detectable by comparing the canonical digest to the submitted EnvelopeDigest. These rules ensure that mutated candidate inputs cannot be mistaken for canonical SDLP envelopes. G.3. Transition Vector Serialization Rules Transition vectors MUST be serialized deterministically according to the following rules: * JSON object keys sorted lexicographically. * CBOR maps sorted by key according to RFC 8949 Section 4.2.1. * All verification-stage fields MUST appear, even when UNDEFINED. * Positive cases MUST NOT include a failure_code. * Negative cases MUST include a failure_code. * Canonical SDLP envelope and candidate input MUST NOT appear simultaneously. * canonical_preimage MUST always be present. These rules ensure that transition vectors are stable evidence artifacts suitable for SCITT, EMILIA, CAID, AEC, and AEB consumption. G.4. CBOR Deterministic Encoding Requirements When encoded in CBOR, transition vectors MUST follow RFC 8949 deterministic encoding: * Major type 3 (text strings) encoded with definite length. * Major type 4 (arrays) encoded with definite length. * Major type 5 (maps) encoded with lexicographically sorted keys. * No indefinite-length strings or maps. * No floating-point values. * No CBOR tags unless using private-use tags defined in Appendix E. These rules ensure that CBOR-encoded transition vectors are stable and reproducible across implementations. G.5. Digest Construction Requirements Digest construction MUST follow these rules: * Canonical preimage MUST be serialized deterministically. * Digest algorithm MUST be SHA-256 unless otherwise specified. * Digest MUST be computed over the exact byte sequence of the canonical preimage. * Digest MUST be encoded as lowercase hexadecimal. Mutated candidate inputs MUST NOT alter the canonical preimage used for digest construction. G.6. Summary Deterministic serialization ensures that: * canonical SDLP envelopes are reproducible, * mutated candidate inputs cannot masquerade as canonical, * transition vectors are stable evidence artifacts, * SCITT and EMILIA systems can reliably consume and verify results. These rules define the serialization boundary between SDLP canonical semantics and external verification systems. Appendix H. Test Suite Index This appendix defines the complete test suite index for transition vectors evaluated under this interoperability profile. The index organizes positive and negative cases according to the multi-stage verification chain defined in Section 6. Each test case corresponds to a runnable transition vector defined in Appendices A–F. H.1. Canonical SDLP Validation Tests H1-POS-001 Canonical envelope, valid digest, valid preimage H1-NEG-001 Digest mismatch (canonical mismatch) H1-NEG-002 Non-canonical preimage H1-NEG-003 Lineage mutation (semantic violation) H1-NEG-004 BodyDigest mismatch (content tampering) H1-NEG-005 Timestamp format violation H.2. Signature Verification Tests H2-POS-001 Valid Ed25519 signature H2-POS-002 Valid ECDSA-P256 signature H2-NEG-001 Invalid signature bytes H2-NEG-002 Wrong public key for signature H2-NEG-003 Unsupported signature suite H2-NEG-004 Trust-root mismatch H.3. CAID Projection Tests H3-POS-001 Correct CAID projection for ownership-binding H3-POS-002 Correct CAID projection for lifecycle-update H3-NEG-001 CAID mismatch (wrong action) H3-NEG-002 CAID projection undefined due to canonical failure H3-NEG-003 CAID projection undefined due to signature failure H.4. AEC Evidence Evaluation Tests H4-POS-001 Evidence SATISFIED (valid enrollment-proof) H4-POS-002 Evidence SATISFIED (multi-element chain) H4-NEG-001 Evidence UNSATISFIED (missing enrollment-proof) H4-NEG-002 Evidence UNSATISFIED (wrong authority domain) H4-NEG-003 Evidence UNSATISFIED (version too low) H4-NEG-004 Evidence UNDEFINED due to earlier failure H.5. Authority Evaluation Tests H5-POS-001 AUTHORIZED under owner-binding-policy:v2 H5-POS-002 AUTHORIZED under lifecycle-policy:v1 H5-NEG-001 REFUSED (signer not enrolled) H5-NEG-002 REFUSED (policy mismatch) H5-NEG-003 REFUSED (revoked credential) H5-NEG-004 UNDEFINED due to earlier failure H.6. AEB Execution Tests H6-POS-001 Execution result BOUND (ownership-binding) H6-POS-002 Execution result UPDATED (lifecycle-update) H6-NEG-001 NOT_EXECUTED due to evidence failure H6-NEG-002 NOT_EXECUTED due to authorization refusal H6-NEG-003 NOT_EXECUTED due to canonical mismatch H6-NEG-004 NOT_EXECUTED due to CAID mismatch H.7. Combined Multi-Stage Failure Tests H7-NEG-001 Canonical mismatch + CAID mismatch + evidence failure H7-NEG-002 Invalid signature + authority refusal H7-NEG-003 Mutated candidate input + trust-root mismatch H7-NEG-004 Multi-stage failure (all stages fail independently) H.8. Positive/Negative Pair Tests H8-PAIR-001 Positive canonical binding + mutated negative binding H8-PAIR-002 Positive lifecycle update + unauthorized negative update H8-PAIR-003 Positive evidence chain + unsatisfied evidence chain H8-PAIR-004 Positive execution + execution-precondition failure H.9. Serialization and Encoding Tests H9-POS-001 Deterministic JSON serialization (canonical) H9-POS-002 Deterministic CBOR serialization (canonical) H9-NEG-001 Non-deterministic JSON ordering (should fail) H9-NEG-002 CBOR indefinite-length map (should fail) H9-NEG-003 CBOR tag misuse (non-IANA tag outside private range) H.10. Summary This test suite index defines the complete set of positive and negative cases required to validate SDLP canonical semantics, CAID projection, AEC evidence evaluation, authority policy evaluation, AEB execution semantics, and deterministic serialization rules. Each test case corresponds to a runnable transition vector defined in Appendices A–F. Appendix I. Transition Vector ABNF This appendix defines the ABNF grammar for transition vectors produced under this interoperability profile. The grammar reflects the multi-stage verification chain defined in Section 6 and the candidate input rules defined in Section 7. ABNF describes the logical structure of the transition vector; JSON and CBOR serialization rules are defined in Appendix G. I.1. Core Structure transition-vector = 1*( tv-field ) tv-field = sdlp-envelope / candidate-input / canonical-preimage / signature-block / caid-block / aec-block / authorization-block / aeb-block / failure-code ; Exactly one of sdlp-envelope or candidate-input MUST appear. ; failure-code MUST appear for negative cases and MUST NOT appear for positive cases. I.2. SDLP Envelope sdlp-envelope = "sdlp_envelope" ":" envelope-object envelope-object = "{" envelope-field *( "," envelope-field ) "}" envelope-field = digitalid-field / lineage-field / lifecycle-field / timestamp-field / bodydigest-field / envelopedigest-field digitalid-field = "\"DigitalID\"" ":" string lifecycle-field = "\"Lifecycle\"" ":" string timestamp-field = "\"Timestamp\"" ":" rfc3339 bodydigest-field = "\"BodyDigest\"" ":" digest envelopedigest-field= "\"EnvelopeDigest\"" ":" digest lineage-field = "\"Lineage\"" ":" "{" lineage-parent "," lineage-sequence "}" lineage-parent = "\"parent\"" ":" ( string / "null" ) lineage-sequence= "\"sequence\"" ":" integer I.3. Mutated Candidate Input candidate-input = "candidate_input" ":" envelope-object ; Same structure as sdlp-envelope, but may contain mutated values. I.4. Canonical Preimage canonical-preimage = "\"canonical_preimage\"" ":" string I.5. Signature Block signature-block = "\"signature\"" ":" "{" sig-suite "," sig-public-key "," sig-signature "," sig-result "}" sig-suite = "\"suite\"" ":" string sig-public-key = "\"public_key\"" ":" string sig-signature = "\"signature\"" ":" string sig-result = "\"verification_result\"" ":" sig-status sig-status = "\"VALID\"" / "\"INVALID\"" I.6. CAID Block caid-block = "\"caid\"" ":" "{" caid-action "," caid-projection "," caid-result "}" caid-action = "\"action\"" ":" string caid-projection = "\"projection\"" ":" string caid-result = "\"projection_result\"" ":" caid-status caid-status = "\"MATCH\"" / "\"MISMATCH\"" I.7. AEC Block aec-block = "\"aec\"" ":" "{" aec-required "," aec-result "}" aec-required = "\"required\"" ":" "{" aec-type [ "," aec-domain ] [ "," aec-version ] "}" aec-type = "\"evidence_type\"" ":" string aec-domain = "\"authority_domain\"" ":" string aec-version = "\"min_version\"" ":" integer aec-result = "\"result\"" ":" aec-status aec-status = "\"SATISFIED\"" / "\"UNSATISFIED\"" / "\"UNDEFINED\"" I.8. Authorization Block authorization-block = "\"authorization\"" ":" "{" authz-ref "," authz-result "}" authz-ref = "\"authority_reference\"" ":" string authz-result = "\"result\"" ":" authz-status authz-status = "\"AUTHORIZED\"" / "\"REFUSED\"" / "\"UNDEFINED\"" I.9. AEB Block aeb-block = "\"aeb\"" ":" "{" aeb-result [ "," aeb-timestamp ] "}" aeb-result = "\"execution_result\"" ":" aeb-status aeb-timestamp = "\"execution_timestamp\"" ":" rfc3339 aeb-status = "\"BOUND\"" / "\"NOT_EXECUTED\"" / "\"UNDEFINED\"" I.10. Failure Code failure-code = "\"failure_code\"" ":" string ; Required for negative cases. ; MUST NOT appear for positive cases. I.11. Common Types string = DQUOTE *CHAR DQUOTE integer = 1*DIGIT digest = string rfc3339 = string ; RFC 3339 timestamp, validated externally I.12. Summary This ABNF grammar defines the logical structure of transition vectors. It ensures that: * canonical SDLP envelopes and mutated candidate inputs are distinct, * verification stages are represented independently, * authority and evidence results are typed, * AEB execution semantics are explicit, * negative cases include pinned failure codes, * serialization rules (Appendix G) can be applied consistently. ABNF defines structure; JSON and CBOR define encoding. Appendix J. End‑to‑End Verifier Walkthrough This appendix provides an end‑to‑end walkthrough of how a production verifier evaluates a submitted SDLP object or candidate input. The walkthrough illustrates the multi‑stage verification chain defined in Section 6 and the transition vector structure defined in Section 7. J.1. Submission A verifier receives one of the following: * a canonical SDLP envelope, or * a mutated candidate input (altered DigitalID, lineage, digest, or body content). The verifier does not assume the submission is canonical. Canonical validation is the first stage of the verification chain. J.2. Stage 1: SDLP Canonical Validation The verifier reconstructs the canonical preimage according to SDLP deterministic serialization rules (Appendix G). It then computes the digest and compares it to the submitted EnvelopeDigest. Outcomes: * VALID — canonical envelope matches canonical preimage. * INVALID — digest mismatch, lineage violation, timestamp violation, or non‑canonical preimage. The transition vector records: { "canonical_validation": { "digest_match": "MATCH" / "MISMATCH", "canonical_result": "VALID" / "INVALID" } } Canonical failure does not stop the verification chain; subsequent stages may still be evaluated. J.3. Stage 2: Signature Verification The verifier extracts the signature suite and key material and performs cryptographic verification over the canonical preimage. Outcomes: * VALID — signature authenticates the signer. * INVALID — signature does not authenticate the signer. Signature verification authenticates the signer but does not establish authority. Transition vector: { "signature": { "suite": "...", "public_key": "...", "signature": "...", "verification_result": "VALID" / "INVALID" } } J.4. Stage 3: CAID Projection The verifier projects the submitted action into a Canonical Action Identifier (CAID) according to draft‑schrock‑canonical‑action‑identifier‑01. Outcomes: * MATCH — submitted action corresponds to the expected CAID. * MISMATCH — submitted action does not correspond to the expected CAID. CAID projection does not evaluate evidence or authority. Transition vector: { "caid": { "action": "...", "projection": "caid:...", "projection_result": "MATCH" / "MISMATCH" } } J.5. Stage 4: AEC Evidence Evaluation The verifier evaluates the Authorization Evidence Chain (AEC) defined in draft‑schrock‑ep‑authorization‑evidence‑chain‑04. Outcomes: * SATISFIED — required evidence is present and valid. * UNSATISFIED — required evidence is missing or invalid. * UNDEFINED — earlier failure prevents evidence evaluation. Transition vector: { "aec": { "required": { ... }, "result": "SATISFIED" / "UNSATISFIED" / "UNDEFINED" } } AEC results are computed by the verifier; submitted artifacts MUST NOT assert their own evidence results. J.6. Stage 5: Local Authorization Decision The verifier evaluates the signer’s authority under the referenced authority policy. Outcomes: * AUTHORIZED — signer is permitted to bind the named owner or domain. * REFUSED — signer is not authorized. * UNDEFINED — earlier failure prevents authority evaluation. Transition vector: { "authorization": { "authority_reference": "...", "result": "AUTHORIZED" / "REFUSED" / "UNDEFINED" } } Authority evaluation is independent of signature verification. J.7. Stage 6: AEB Execution Outcome The verifier evaluates the Action Evidence Boundary (AEB) defined in draft‑schrock‑action‑evidence‑boundary‑00. Outcomes: * BOUND / UPDATED / other action‑specific result — action executed. * NOT_EXECUTED — action not executed due to earlier failure. * UNDEFINED — execution semantics not applicable. Transition vector: { "aeb": { "execution_result": "BOUND" / "NOT_EXECUTED" / "UNDEFINED", "execution_timestamp": "RFC3339 timestamp" } } Execution occurs only for admitted actions. J.8. Negative Case Handling Negative cases MUST include a pinned failure code describing the expected failure under the referenced trust root, authority policy, and verification chain. Example: { "failure_code": "CANONICAL_MISMATCH" } Negative cases may arise from: * invalid signatures, * unauthorized signers, * CAID mismatches, * unsatisfied evidence, * canonical mismatches, * mutated candidate inputs, * trust‑root mismatches, * execution precondition failures. J.9. Final Transition Vector Assembly The verifier assembles all stage results into a single transition vector: { sdlp_envelope | candidate_input, canonical_preimage, signature, caid, aec, authorization, aeb, [ failure_code ] } Positive cases omit failure_code. Negative cases MUST include failure_code. J.10. Summary This walkthrough illustrates the complete evaluation pipeline for submitted SDLP objects and candidate inputs. Each stage is evaluated independently, and results are recorded as typed fields in the transition vector. This structure preserves the separation of SDLP canonical semantics from external verification systems such as CAID, AEC, AEB, SCITT, and EMILIA. Appendix K. Worked Multi‑Stage Failure Trace This appendix provides a complete multi‑stage failure trace for a transition vector that fails at several independent points in the verification chain. The example illustrates how canonical validation, signature verification, CAID projection, AEC evidence evaluation, authority evaluation, and AEB execution semantics interact when multiple failures occur. K.1. Submission The verifier receives a mutated candidate input: { "DigitalID": "did:sdlp:TAMPERED-OBJECT-777", "Lineage": { "parent": "did:sdlp:NONEXISTENT", "sequence": 42 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:TAMPERED-BODY-777...", "EnvelopeDigest": "sha256:WRONG-DIGEST-777..." } The submission is structurally valid JSON, but not canonical. K.2. Stage 1: Canonical Validation Failure The verifier reconstructs the canonical preimage: "SDLPv1|did:sdlp:EXAMPLE-OBJECT-777|1|active|2026-07-28T07:00:00Z|abcd1234..." The digest does not match the submitted EnvelopeDigest. { "canonical_validation": { "digest_match": "MISMATCH", "canonical_result": "INVALID", "lineage_semantics": "INVALID" } } Canonical failure does not stop the chain; subsequent stages continue. K.3. Stage 2: Signature Verification Failure The signature is syntactically valid but does not authenticate the signer over the canonical preimage. { "signature": { "suite": "Ed25519", "public_key": "ed25519:unauthorized-key-XYZ", "signature": "sig:deadbeef...", "verification_result": "INVALID" } } Signature failure does not stop the chain; CAID projection is still attempted. K.4. Stage 3: CAID Projection Failure The submitted action claims "ownership-binding", but the mutated candidate input does not correspond to the expected CAID. { "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MISMATCH" } } CAID mismatch prevents meaningful evidence evaluation, but the verifier still records the AEC stage. K.5. Stage 4: AEC Evidence Failure The required evidence chain cannot be satisfied: * signer is not enrolled, * canonical envelope is invalid, * CAID projection mismatched. { "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 }, "result": "UNSATISFIED" } } K.6. Stage 5: Authority Evaluation Failure The signer is authenticated as INVALID and has no valid enrollment under the referenced authority policy. { "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "REFUSED" } } K.7. Stage 6: AEB Execution Failure Execution is not permitted because: * canonical envelope is invalid, * signature is invalid, * CAID projection mismatched, * evidence unsatisfied, * authorization refused. { "aeb": { "execution_result": "NOT_EXECUTED" } } K.8. Pinned Failure Code Although multiple failures occurred, the pinned failure code identifies the *primary expected failure* under the trust root and authority policy. In this case, the canonical mismatch is the earliest and most fundamental failure. { "failure_code": "CANONICAL_MISMATCH" } K.9. Complete Multi‑Stage Failure Transition Vector { "candidate_input": { "DigitalID": "did:sdlp:TAMPERED-OBJECT-777", "Lineage": { "parent": "did:sdlp:NONEXISTENT", "sequence": 42 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:TAMPERED-BODY-777...", "EnvelopeDigest": "sha256:WRONG-DIGEST-777..." }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-777|1|active|2026-07-28T07:00:00Z|abcd1234...", "canonical_validation": { "digest_match": "MISMATCH", "canonical_result": "INVALID", "lineage_semantics": "INVALID" }, "signature": { "suite": "Ed25519", "public_key": "ed25519:unauthorized-key-XYZ", "signature": "sig:deadbeef...", "verification_result": "INVALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MISMATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 }, "result": "UNSATISFIED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "REFUSED" }, "aeb": { "execution_result": "NOT_EXECUTED" }, "failure_code": "CANONICAL_MISMATCH" } K.10. Summary This multi‑stage failure trace demonstrates: * how failures propagate through the verification chain, * how each stage records its own typed result, * how negative cases remain structurally identical to positive cases, * how the pinned failure code identifies the primary expected failure. This example is suitable for use in automated test harnesses and interoperability evaluations. Appendix L. Verifier Pseudocode This appendix provides implementation‑neutral pseudocode for a production verifier that evaluates SDLP envelopes and mutated candidate inputs according to the multi‑stage verification chain defined in Section 6. The pseudocode produces a transition vector consistent with Sections 7–8 and Appendices A–K. L.1. Overview The verifier performs the following stages: 1. Canonical SDLP validation 2. Signature verification 3. CAID projection 4. AEC evidence evaluation 5. Authorization evaluation 6. AEB execution semantics 7. Final transition vector assembly Each stage records a typed result. Negative cases include a pinned failure code. L.2. Pseudocode function VERIFY(submission): tv = new TransitionVector() if isCanonicalSubmission(submission): tv.sdlp_envelope = submission else: tv.candidate_input = submission // ------------------------------------------------------------ // Stage 1: Canonical SDLP Validation // ------------------------------------------------------------ canonical = buildCanonicalPreimage(submission) tv.canonical_preimage = canonical digest = sha256(canonical) submittedDigest = submission.EnvelopeDigest if digest == submittedDigest: tv.canonical_validation.digest_match = "MATCH" tv.canonical_validation.canonical_result = "VALID" else: tv.canonical_validation.digest_match = "MISMATCH" tv.canonical_validation.canonical_result = "INVALID" if violatesLineageSemantics(submission): tv.canonical_validation.lineage_semantics = "INVALID" // ------------------------------------------------------------ // Stage 2: Signature Verification // ------------------------------------------------------------ sig = submission.signature if verifySignature(sig.public_key, canonical, sig.signature): tv.signature.verification_result = "VALID" else: tv.signature.verification_result = "INVALID" tv.signature.suite = sig.suite tv.signature.public_key = sig.public_key tv.signature.signature = sig.signature // ------------------------------------------------------------ // Stage 3: CAID Projection // ------------------------------------------------------------ action = extractAction(submission) projection = projectCAID(action) tv.caid.action = action tv.caid.projection = projection if projectionMatches(action, projection): tv.caid.projection_result = "MATCH" else: tv.caid.projection_result = "MISMATCH" // ------------------------------------------------------------ // Stage 4: AEC Evidence Evaluation // ------------------------------------------------------------ requiredEvidence = lookupRequiredEvidence(action) tv.aec.required = requiredEvidence if tv.canonical_validation.canonical_result == "INVALID": tv.aec.result = "UNDEFINED" else if tv.signature.verification_result == "INVALID": tv.aec.result = "UNDEFINED" else if tv.caid.projection_result == "MISMATCH": tv.aec.result = "UNDEFINED" else if evidenceSatisfied(requiredEvidence, submission): tv.aec.result = "SATISFIED" else: tv.aec.result = "UNSATISFIED" // ------------------------------------------------------------ // Stage 5: Authorization Evaluation // ------------------------------------------------------------ authzRef = lookupAuthorityReference(action) tv.authorization.authority_reference = authzRef if tv.aec.result == "SATISFIED" and signerAuthorized(sig.public_key, authzRef): tv.authorization.result = "AUTHORIZED" else if tv.aec.result == "UNSATISFIED": tv.authorization.result = "REFUSED" else: tv.authorization.result = "UNDEFINED" // ------------------------------------------------------------ // Stage 6: AEB Execution Semantics // ------------------------------------------------------------ if tv.authorization.result == "AUTHORIZED": tv.aeb.execution_result = executeAction(action, submission) tv.aeb.execution_timestamp = nowRFC3339() else: tv.aeb.execution_result = "NOT_EXECUTED" // ------------------------------------------------------------ // Stage 7: Failure Code (Negative Cases Only) // ------------------------------------------------------------ if tv.canonical_validation.canonical_result == "INVALID": tv.failure_code = "CANONICAL_MISMATCH" else if tv.signature.verification_result == "INVALID": tv.failure_code = "SIG_INVALID" else if tv.caid.projection_result == "MISMATCH": tv.failure_code = "CAID_MISMATCH" else if tv.aec.result == "UNSATISFIED": tv.failure_code = "AEC_UNSATISFIED" else if tv.authorization.result == "REFUSED": tv.failure_code = "AUTHZ_REFUSED" else if tv.aeb.execution_result == "NOT_EXECUTED": tv.failure_code = "AEB_PRECONDITION_FAILED" else: // Positive case: no failure code remove tv.failure_code return tv L.3. Notes * Each stage is evaluated independently. * Earlier failures propagate but do not halt the chain. * Negative cases MUST include a pinned failure code. * Positive cases MUST NOT include a failure code. * Canonical SDLP semantics are never modified by external systems. * Evidence results (AEC) MUST be computed by the verifier, not asserted by submitted artifacts. * Execution semantics (AEB) apply only to admitted actions. L.4. Summary This pseudocode defines a complete, deterministic verifier pipeline suitable for SDLP, CAID, AEC, AEB, SCITT, and EMILIA systems. It ensures consistent transition vector construction across implementations and preserves the separation of canonical SDLP semantics from external verification stages. Appendix M. End‑to‑End SCITT/EMILIA Integration Example This appendix provides a complete end‑to‑end example showing how a transition vector produced by an SDLP/CAID/AEC/AEB verifier is registered in SCITT and consumed by EMILIA. The example illustrates the separation of canonical SDLP semantics from external verification systems and the role of SCITT transparency services in recording submitted statements. M.1. Overview The end‑to‑end flow consists of the following steps: 1. Submission of an SDLP envelope or candidate input. 2. Local verification (SDLP → CAID → AEC → AUTHZ → AEB). 3. Construction of a transition vector. 4. Submission of the transition vector to a SCITT transparency service. 5. SCITT registration and receipt issuance. 6. EMILIA ingestion of the transition vector and SCITT receipt. 7. EMILIA policy evaluation and transparency record construction. SCITT records *registration*, not *truth*. EMILIA evaluates *policy*, not *canonical SDLP semantics*. M.2. Step 1: Submission A canonical SDLP envelope is submitted: { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-200", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:abcd2000...", "EnvelopeDigest": "sha256:9988aabb2000..." } M.3. Step 2: Local Verification The verifier performs: * canonical SDLP validation, * signature verification, * CAID projection, * AEC evidence evaluation, * authority evaluation, * AEB execution semantics. All stages succeed. M.4. Step 3: Transition Vector Construction The verifier constructs: { "sdlp_envelope": { ...canonical envelope... }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-200|1|active|2026-07-28T07:00:00Z|abcd2000...", "signature": { "suite": "Ed25519", "public_key": "ed25519:authz-key-200", "signature": "sig:1122aabb2000...", "verification_result": "VALID" }, "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MATCH" }, "aec": { "required": { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 }, "result": "SATISFIED" }, "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "AUTHORIZED" }, "aeb": { "execution_result": "BOUND", "execution_timestamp": "2026-07-28T07:00:01Z" } } No failure_code is present because this is a positive case. M.5. Step 4: Submission to SCITT The transition vector is submitted to a SCITT transparency service. SCITT does not evaluate: * canonical SDLP semantics, * signature validity, * evidence satisfaction, * authority, * execution semantics. SCITT only records the statement. M.6. Step 5: SCITT Registration and Receipt SCITT returns a receipt: { "scitt_receipt": { "registration_hash": "sha256:scitt-reg-200...", "timestamp": "2026-07-28T07:00:02Z", "transparency_log": "scitt.example.com/logs/main", "receipt_signature": "sig:scitt-signed-200..." } } A SCITT receipt proves: * the statement was registered, * the transparency log accepted it, * the log signed the receipt. A SCITT receipt does *not* prove: * the statement is canonical, * the signer is authorized, * the evidence is satisfied, * the action is admitted. M.7. Step 6: EMILIA Ingestion EMILIA receives: * the transition vector, * the SCITT receipt. EMILIA performs: * structural validation, * policy lookup, * evidence interpretation, * authority domain mapping, * action classification. EMILIA does *not* recompute canonical SDLP semantics. M.8. Step 7: EMILIA Policy Evaluation EMILIA evaluates the action under its policy model: { "emilia_policy": { "action_class": "ownership-binding", "evidence_state": "SATISFIED", "authority_state": "AUTHORIZED", "execution_state": "BOUND", "transparency_state": "REGISTERED" } } EMILIA may produce a transparency record: { "emilia_transparency_record": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-200", "action": "ownership-binding", "admission": "ADMITTED", "execution": "BOUND", "scitt_receipt_hash": "sha256:scitt-reg-200..." } } M.9. Summary This end‑to‑end example demonstrates: * SDLP defines canonical semantics. * CAID defines action identity. * AEC defines evidence requirements. * AUTHZ defines authority. * AEB defines execution semantics. * SCITT records registration, not truth. * EMILIA evaluates policy, not canonical SDLP semantics. The transition vector is the interoperability boundary between all systems. Appendix N. Transition Vector Storage & Retrieval Model This appendix defines the storage and retrieval model for transition vectors produced under this interoperability profile. The model is implementation‑neutral and focuses on the interoperability boundary between SDLP verifiers, SCITT transparency services, and EMILIA policy engines. N.1. Overview Transition vectors are immutable evidence artifacts. Once produced, they may be: * stored locally by the verifier, * registered in a SCITT transparency service, * ingested by EMILIA for policy evaluation, * retrieved later for audit, replay, or lineage analysis. The storage model ensures: * immutability, * deterministic retrieval, * stable indexing, * compatibility with SCITT receipts, * compatibility with EMILIA transparency records. N.2. Storage Requirements A storage system MUST support: * immutable records, * deterministic serialization (Appendix G), * stable identifiers, * retrieval by DigitalID, * retrieval by SCITT receipt hash, * retrieval by authority domain, * retrieval by action class (CAID), * retrieval by timestamp range. Storage MAY be implemented using: * object stores, * document databases, * append‑only logs, * SCITT transparency logs, * EMILIA evidence stores. The storage format MUST preserve the exact transition vector without modification. N.3. Primary Index Keys A transition vector MUST be indexable by the following keys: * DigitalID * EnvelopeDigest * canonical_preimage hash * CAID projection * AEC evidence type * authority_reference * execution_result * failure_code (negative cases only) * SCITT registration hash (if present) These keys allow efficient lookup across SDLP, CAID, AEC, AEB, SCITT, and EMILIA systems. N.4. SCITT Registration Binding When a transition vector is registered in SCITT, the storage system MUST bind: * the transition vector, * the SCITT receipt, * the SCITT registration hash. Example binding: { "transition_vector_hash": "sha256:tv-EXAMPLE-300...", "scitt_registration_hash": "sha256:scitt-reg-300...", "scitt_receipt": { ...receipt... } } SCITT registration does not modify the transition vector. N.5. EMILIA Ingestion Binding When EMILIA ingests a transition vector, it MAY bind: * the transition vector, * the SCITT receipt (if present), * the EMILIA transparency record. Example binding: { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-300", "transition_vector_hash": "sha256:tv-EXAMPLE-300...", "emilia_transparency_record": { ...record... } } EMILIA does not recompute canonical SDLP semantics. N.6. Retrieval Model A retrieval system MUST support the following queries: * get_by_digitalid(DigitalID) * get_by_envelope_digest(EnvelopeDigest) * get_by_transition_vector_hash(hash) * get_by_scitt_registration_hash(hash) * get_by_authority_reference(authz) * get_by_action_class(caid) * get_by_execution_result(result) * get_by_failure_code(code) * get_by_timestamp_range(start, end) Retrieval MUST return the exact stored transition vector. N.7. Versioning Model Transition vectors are immutable. If a new evaluation occurs: * a new transition vector MUST be created, * the old transition vector MUST NOT be modified, * lineage MAY be expressed via: { "supersedes": "sha256:tv-old...", "superseded_by": "sha256:tv-new..." } Versioning does not alter canonical SDLP semantics. N.8. Replay Model A verifier MAY replay a transition vector by: * re‑evaluating the canonical preimage, * re‑verifying the signature, * re‑projecting CAID, * re‑evaluating evidence, * re‑evaluating authority, * re‑evaluating execution semantics. Replay MUST NOT modify the stored transition vector. N.9. Audit Model An audit system MUST be able to: * retrieve all transition vectors for a DigitalID, * retrieve all SCITT receipts for those vectors, * retrieve all EMILIA transparency records, * reconstruct the full lifecycle of the object. Audit systems MUST NOT modify stored transition vectors. N.10. Summary This storage and retrieval model ensures that transition vectors: * remain immutable evidence artifacts, * can be indexed and retrieved deterministically, * integrate cleanly with SCITT transparency services, * integrate cleanly with EMILIA policy engines, * support audit, replay, and lineage analysis. Transition vectors form the interoperability boundary between SDLP canonical semantics and external verification systems. Appendix O. Security Domain Separation Rationale This appendix explains the rationale for separating SDLP canonical semantics, CAID action identity, AEC evidence evaluation, AUTHZ authority evaluation, AEB execution semantics, SCITT transparency registration, and EMILIA policy evaluation into distinct security domains. The separation prevents cross‑domain privilege escalation, semantic contamination, and verifier ambiguity. O.1. Overview The interoperability profile defines seven independent security domains: 1. SDLP canonical semantics 2. CAID action identity 3. AEC evidence evaluation 4. AUTHZ authority evaluation 5. AEB execution semantics 6. SCITT transparency registration 7. EMILIA policy evaluation Each domain has its own trust model, failure modes, and verification responsibilities. No domain is permitted to assert or override the semantics of another. O.2. SDLP Canonical Semantics Domain SDLP defines: * canonical envelopes, * deterministic serialization, * digest construction, * lineage semantics. SDLP does NOT define: * authority, * evidence, * action identity, * execution semantics. Rationale: * Prevents external systems from altering canonical object identity. * Ensures that canonical digests remain stable across ecosystems. * Guarantees that mutated candidate inputs cannot masquerade as canonical envelopes. O.3. CAID Action Identity Domain CAID defines: * the canonical identity of an action, * the projection rules for submitted actions. CAID does NOT define: * evidence, * authority, * execution semantics. Rationale: * Prevents action identity from being inferred from evidence or authority. * Ensures that action classification is deterministic and stable. O.4. AEC Evidence Evaluation Domain AEC defines: * required evidence types, * evidence chain semantics, * evidence satisfaction rules. AEC does NOT define: * canonical SDLP semantics, * action identity, * authority, * execution semantics. Rationale: * Prevents evidence from being used to assert canonical identity. * Prevents evidence from asserting authority. * Ensures evidence is evaluated independently of action identity. O.5. AUTHZ Authority Evaluation Domain AUTHZ defines: * whether a signer is authorized under a policy, * whether evidence is sufficient for authority. AUTHZ does NOT define: * canonical SDLP semantics, * action identity, * execution semantics. Rationale: * Prevents authority from being inferred from canonical identity. * Prevents authority from being inferred from CAID projection. * Prevents authority from being inferred from SCITT registration. O.6. AEB Execution Semantics Domain AEB defines: * whether an action is executed, * the result of execution, * execution timestamps. AEB does NOT define: * canonical SDLP semantics, * action identity, * evidence, * authority. Rationale: * Prevents execution from being used to assert authority. * Prevents execution from being used to assert canonical identity. * Ensures execution semantics remain independent of SCITT or EMILIA. O.7. SCITT Transparency Registration Domain SCITT defines: * registration of statements, * transparency log semantics, * receipt issuance. SCITT does NOT define: * canonical SDLP semantics, * evidence, * authority, * execution semantics. Rationale: * Prevents transparency logs from asserting truth. * Prevents SCITT receipts from being misinterpreted as evidence. * Ensures SCITT remains a registration system, not a verifier. O.8. EMILIA Policy Evaluation Domain EMILIA defines: * policy interpretation, * transparency record construction, * domain‑specific admission semantics. EMILIA does NOT define: * canonical SDLP semantics, * evidence semantics, * authority semantics, * execution semantics. Rationale: * Prevents EMILIA from altering canonical SDLP semantics. * Prevents EMILIA from asserting evidence or authority. * Ensures EMILIA remains a policy engine, not a canonical verifier. O.9. Cross‑Domain Contamination Risks Without strict separation, the following risks arise: * evidence could be misinterpreted as canonical identity, * SCITT registration could be misinterpreted as authorization, * EMILIA policy results could be misinterpreted as execution results, * CAID projection could be misinterpreted as evidence satisfaction, * execution results could be misinterpreted as canonical validity. The profile prohibits all such cross‑domain contamination. O.10. Transition Vector as the Interoperability Boundary The transition vector is the only structure that crosses domains. It records: * canonical SDLP results, * CAID results, * AEC results, * AUTHZ results, * AEB results, * SCITT receipts (optional), * EMILIA transparency records (optional). The transition vector does NOT allow any domain to override another. O.11. Summary Security domain separation ensures: * canonical SDLP semantics remain authoritative, * action identity remains deterministic, * evidence evaluation remains independent, * authority evaluation remains policy‑bound, * execution semantics remain isolated, * SCITT remains a transparency system, * EMILIA remains a policy engine. This separation prevents privilege escalation, semantic contamination, and verifier ambiguity across the ecosystem. Appendix P. Privacy & Minimization Considerations This appendix defines the privacy and data‑minimization requirements for SDLP envelopes, transition vectors, CAID projections, AEC evidence artifacts, AUTHZ authority references, AEB execution results, SCITT receipts, and EMILIA transparency records. These requirements ensure that systems participating in this interoperability profile do not leak unnecessary personal or organizational information. P.1. Overview Privacy protection is achieved through: * strict minimization of fields, * separation of security domains (Appendix O), * deterministic serialization (Appendix G), * immutable evidence artifacts (Appendix N), * explicit failure codes (Appendices B–F), * non‑assertive SCITT registration semantics (Appendix M). No system is permitted to infer, derive, or reconstruct personal information beyond what is explicitly provided. P.2. SDLP Envelope Minimization SDLP envelopes MUST NOT contain: * personal identifiers, * organizational identifiers beyond DigitalID, * embedded credentials, * embedded evidence, * embedded authority assertions. SDLP envelopes MUST contain only: * DigitalID, * Lineage, * Lifecycle, * Timestamp, * BodyDigest, * EnvelopeDigest. Rationale: * Prevents canonical SDLP semantics from leaking identity or authority information. * Ensures canonical digests remain privacy‑neutral. P.3. Transition Vector Minimization Transition vectors MUST NOT include: * raw evidence artifacts, * raw credentials, * personal identity information, * policy documents, * SCITT log internals, * EMILIA policy internals. Transition vectors MUST include only typed results: * signature.verification_result, * caid.projection_result, * aec.result, * authorization.result, * aeb.execution_result. Rationale: * Prevents transition vectors from becoming privacy‑sensitive logs. * Ensures interoperability without exposing internal system details. P.4. Evidence Minimization (AEC Domain) AEC evaluation MUST NOT expose: * raw enrollment proofs, * credential contents, * certificate chains, * revocation lists, * authority metadata. AEC MUST expose only: * evidence_type, * authority_domain, * min_version, * result. Rationale: * Prevents evidence artifacts from leaking sensitive identity data. * Ensures evidence semantics remain abstract and typed. P.5. Authority Minimization (AUTHZ Domain) AUTHZ evaluation MUST NOT expose: * signer identity, * credential contents, * policy internals, * authorization reasoning. AUTHZ MUST expose only: * authority_reference, * result. Rationale: * Prevents authority systems from leaking identity or policy details. * Ensures authorization semantics remain abstract and typed. P.6. Execution Minimization (AEB Domain) AEB MUST NOT expose: * execution logs, * internal state transitions, * policy reasoning, * operational metadata. AEB MUST expose only: * execution_result, * execution_timestamp. Rationale: * Prevents execution systems from leaking operational details. * Ensures execution semantics remain abstract and typed. P.7. SCITT Minimization SCITT MUST NOT expose: * signer identity, * evidence, * authority, * execution semantics, * canonical SDLP semantics. SCITT MUST expose only: * registration_hash, * timestamp, * transparency_log identifier, * receipt_signature. Rationale: * Prevents transparency logs from leaking sensitive information. * Ensures SCITT remains a registration system, not a verifier. P.8. EMILIA Minimization EMILIA MUST NOT expose: * raw transition vectors, * raw SCITT receipts, * internal policy documents, * internal evaluation reasoning. EMILIA MAY expose: * action_class, * evidence_state, * authority_state, * execution_state, * transparency_state. Rationale: * Prevents EMILIA from leaking sensitive policy or identity data. * Ensures EMILIA remains a policy engine, not a canonical verifier. P.9. Failure Code Minimization Failure codes MUST NOT encode: * personal identifiers, * organizational identifiers, * evidence contents, * authority details. Failure codes MUST be drawn from a fixed, privacy‑neutral vocabulary: * CANONICAL_MISMATCH * SIG_INVALID * CAID_MISMATCH * AEC_UNSATISFIED * AUTHZ_REFUSED * AEB_PRECONDITION_FAILED * MULTI_STAGE_FAILURE Rationale: * Prevents negative cases from leaking sensitive information. * Ensures failure semantics remain abstract and typed. P.10. Cross‑Domain Privacy Protection No domain may infer identity or authority from another domain. Examples: * SCITT registration does not imply authorization. * AEC evidence does not imply canonical identity. * AUTHZ results do not imply execution. * EMILIA transparency records do not imply evidence satisfaction. Rationale: * Prevents privacy leakage through inference. * Preserves strict domain separation (Appendix O). P.11. Summary Privacy and minimization are achieved through: * strict field minimization, * typed results instead of raw artifacts, * immutable transition vectors, * domain separation, * non‑assertive SCITT semantics, * abstract EMILIA policy outputs. These rules ensure that SDLP, CAID, AEC, AUTHZ, AEB, SCITT, and EMILIA can interoperate without leaking sensitive information. Appendix Q. Threat Model & Attack Surface This appendix defines the threat model and attack surface for systems implementing this interoperability profile. It identifies adversarial capabilities, trust boundaries, cross‑domain risks, and mitigations across SDLP canonical semantics, CAID action identity, AEC evidence evaluation, AUTHZ authority evaluation, AEB execution semantics, SCITT transparency registration, and EMILIA policy evaluation. Q.1. Threat Model Overview The threat model assumes: * adversaries may submit arbitrary SDLP envelopes or mutated candidate inputs, * adversaries may possess cryptographic keys, * adversaries may attempt to forge evidence, * adversaries may attempt to bypass authority policies, * adversaries may attempt to exploit SCITT transparency semantics, * adversaries may attempt to confuse EMILIA policy evaluation. The model does NOT assume: * compromise of trust roots, * compromise of authority domains, * compromise of SCITT transparency logs, * compromise of EMILIA policy engines. Q.2. Attacker Capabilities Attackers may: * forge or mutate SDLP envelopes, * submit non‑canonical preimages, * submit invalid signatures, * replay previously valid envelopes, * craft misleading CAID actions, * submit incomplete or forged evidence, * attempt unauthorized actions, * attempt to exploit SCITT registration semantics, * attempt to confuse EMILIA policy evaluation. Attackers may NOT: * alter canonical SDLP semantics, * alter CAID projection rules, * alter AEC evidence requirements, * alter AUTHZ policy semantics, * alter AEB execution semantics, * alter SCITT transparency logs, * alter EMILIA policy rules. Q.3. Attack Surface Summary The attack surface consists of: * SDLP envelope submission, * candidate input submission, * signature verification, * CAID projection, * evidence submission, * authority policy references, * SCITT registration, * EMILIA ingestion. Each surface is isolated by strict domain separation (Appendix O). Q.4. SDLP Canonical Semantics Threats Threats: * forged canonical envelopes, * mutated candidate inputs, * digest mismatch attacks, * lineage manipulation, * timestamp manipulation. Mitigations: * deterministic serialization (Appendix G), * strict canonical preimage rules, * digest comparison, * lineage semantics validation, * timestamp format validation. Q.5. Signature Verification Threats Threats: * invalid signatures, * key substitution attacks, * unsupported signature suites, * trust‑root mismatch. Mitigations: * strict signature suite validation, * canonical preimage signing, * trust‑root binding, * typed verification results. Q.6. CAID Projection Threats Threats: * action spoofing, * projection mismatch, * malformed action identifiers. Mitigations: * deterministic CAID projection rules, * typed projection results, * separation from evidence and authority domains. Q.7. AEC Evidence Threats Threats: * forged evidence, * missing evidence, * stale or revoked evidence, * evidence replay, * evidence substitution. Mitigations: * typed evidence requirements, * independent evidence evaluation, * no raw evidence exposure (Appendix P), * strict versioning rules. Q.8. AUTHZ Authority Threats Threats: * unauthorized signers, * policy spoofing, * policy substitution, * credential misuse. Mitigations: * authority_reference binding, * independent policy evaluation, * typed authorization results, * separation from canonical SDLP semantics. Q.9. AEB Execution Threats Threats: * unauthorized execution, * execution replay, * execution precondition bypass, * execution spoofing. Mitigations: * strict precondition rules, * typed execution results, * execution timestamps, * separation from SCITT and EMILIA semantics. Q.10. SCITT Transparency Threats Threats: * misinterpretation of SCITT registration as truth, * replay of SCITT receipts, * registration flooding, * log spoofing. Mitigations: * SCITT receipts are non‑assertive, * SCITT does not evaluate canonical semantics, * SCITT does not evaluate evidence or authority, * SCITT does not evaluate execution semantics. Q.11. EMILIA Policy Threats Threats: * misinterpretation of EMILIA policy results as canonical truth, * policy substitution, * policy spoofing, * ingestion of malformed transition vectors. Mitigations: * EMILIA does not recompute canonical SDLP semantics, * EMILIA does not evaluate evidence or authority, * EMILIA does not assert execution semantics, * EMILIA uses typed policy outputs. Q.12. Cross‑Domain Threats Threats: * evidence used to assert canonical identity, * SCITT registration used to assert authorization, * EMILIA policy used to assert execution, * CAID projection used to assert evidence satisfaction. Mitigations: * strict domain separation (Appendix O), * typed results, * immutable transition vectors, * privacy minimization (Appendix P). Q.13. Transition Vector Threats Threats: * tampering, * partial disclosure, * field substitution, * failure‑code manipulation. Mitigations: * deterministic serialization, * immutable storage (Appendix N), * typed failure codes, * complete stage recording. Q.14. Summary The threat model ensures: * canonical SDLP semantics remain authoritative, * evidence and authority remain independent, * execution semantics remain isolated, * SCITT remains a transparency system, * EMILIA remains a policy engine, * transition vectors remain immutable evidence artifacts. Strict domain separation is the primary mitigation against cross‑domain attacks. Appendix R. Interop Profile Compliance Checklist This appendix defines the complete compliance checklist for systems implementing this interoperability profile. The checklist covers SDLP canonical semantics, CAID projection, AEC evidence evaluation, AUTHZ authority evaluation, AEB execution semantics, SCITT transparency registration, EMILIA policy evaluation, and transition vector construction. R.1. SDLP Canonical Semantics Compliance A system is compliant if: [ ] It constructs canonical preimages deterministically (Appendix G). [ ] It validates EnvelopeDigest against canonical preimage. [ ] It validates lineage semantics. [ ] It validates timestamp format (RFC 3339). [ ] It does not modify submitted envelopes. [ ] It distinguishes canonical envelopes from mutated candidate inputs. [ ] It records canonical validation results in typed fields. R.2. Signature Verification Compliance A system is compliant if: [ ] It verifies signatures over the canonical preimage. [ ] It validates signature suite identifiers. [ ] It binds verification to a trust root. [ ] It records verification results as VALID or INVALID. [ ] It does not infer authority from signature validity. R.3. CAID Projection Compliance A system is compliant if: [ ] It extracts the submitted action deterministically. [ ] It projects the action into a CAID using canonical rules. [ ] It records projection_result as MATCH or MISMATCH. [ ] It does not infer evidence or authority from CAID projection. R.4. AEC Evidence Evaluation Compliance A system is compliant if: [ ] It loads required evidence types from policy. [ ] It evaluates evidence independently of canonical SDLP semantics. [ ] It records result as SATISFIED, UNSATISFIED, or UNDEFINED. [ ] It does not expose raw evidence artifacts (Appendix P). [ ] It does not infer canonical identity from evidence. R.5. AUTHZ Authority Evaluation Compliance A system is compliant if: [ ] It evaluates authority independently of signature validity. [ ] It binds authority_reference to a stable policy identifier. [ ] It records result as AUTHORIZED, REFUSED, or UNDEFINED. [ ] It does not expose policy internals. [ ] It does not infer canonical identity from authority. R.6. AEB Execution Semantics Compliance A system is compliant if: [ ] It executes actions only when AUTHORIZED. [ ] It records execution_result as BOUND, UPDATED, NOT_EXECUTED, or UNDEFINED. [ ] It records execution_timestamp for admitted actions. [ ] It does not expose internal execution logs. [ ] It does not infer authority or evidence from execution. R.7. Transition Vector Construction Compliance A system is compliant if: [ ] It includes exactly one of sdlp_envelope or candidate_input. [ ] It includes canonical_preimage. [ ] It includes all verification-stage blocks (signature, caid, aec, authorization, aeb). [ ] It includes failure_code for negative cases. [ ] It omits failure_code for positive cases. [ ] It uses typed results for all fields. [ ] It serializes deterministically (Appendix G). [ ] It preserves immutability (Appendix N). R.8. SCITT Transparency Compliance A system is compliant if: [ ] It registers transition vectors without modification. [ ] It issues receipts containing registration_hash, timestamp, log identifier, and signature. [ ] It does not assert canonical SDLP semantics. [ ] It does not assert evidence or authority. [ ] It does not assert execution semantics. R.9. EMILIA Policy Evaluation Compliance A system is compliant if: [ ] It ingests transition vectors and SCITT receipts without modification. [ ] It evaluates policy independently of canonical SDLP semantics. [ ] It records policy outputs as typed states (evidence_state, authority_state, execution_state, transparency_state). [ ] It does not expose raw transition vectors or receipts. [ ] It does not assert canonical SDLP semantics. R.10. Privacy & Minimization Compliance A system is compliant if: [ ] It does not expose raw evidence. [ ] It does not expose raw credentials. [ ] It does not expose policy internals. [ ] It does not expose execution logs. [ ] It uses typed results only. [ ] It uses privacy‑neutral failure codes (Appendix P). R.11. Security Domain Separation Compliance A system is compliant if: [ ] It does not infer canonical identity from evidence. [ ] It does not infer authority from SCITT registration. [ ] It does not infer execution from EMILIA policy. [ ] It does not infer evidence from CAID projection. [ ] It maintains strict domain separation (Appendix O). R.12. Full Compliance Summary A system is fully compliant if: [ ] All SDLP canonical rules are implemented. [ ] All verification stages are evaluated independently. [ ] All typed results are recorded. [ ] All negative cases include failure_code. [ ] All positive cases omit failure_code. [ ] Transition vectors are immutable and deterministic. [ ] SCITT registration is non‑assertive. [ ] EMILIA policy evaluation is non‑canonical. [ ] Privacy and minimization rules are followed. [ ] Security domain separation is preserved. This checklist defines the complete compliance boundary for the interoperability profile. Appendix S. Deterministic Test Harness Specification This appendix defines a deterministic test harness for evaluating SDLP envelopes, mutated candidate inputs, and transition vectors under the interoperability profile. The harness ensures reproducible results across implementations and prevents nondeterministic behavior. S.1. Overview The test harness executes the following deterministic pipeline: 1. Load test vector (canonical or mutated). 2. Construct canonical preimage. 3. Compute digest and compare. 4. Verify signature. 5. Project CAID. 6. Evaluate AEC evidence. 7. Evaluate AUTHZ authority. 8. Evaluate AEB execution semantics. 9. Assemble transition vector. 10. Compare against expected results. All steps MUST be deterministic and MUST NOT depend on external state. S.2. Deterministic Inputs The harness MUST accept: * canonical SDLP envelopes, * mutated candidate inputs, * expected transition vectors, * expected failure codes, * expected typed results for each stage. Inputs MUST be: * UTF‑8 encoded, * deterministically serialized (Appendix G), * immutable. S.3. Deterministic Execution Rules The harness MUST: * use deterministic canonical serialization, * use deterministic digest computation (SHA‑256), * use deterministic signature verification, * use deterministic CAID projection rules, * use deterministic evidence evaluation rules, * use deterministic authority evaluation rules, * use deterministic execution semantics. The harness MUST NOT: * use nondeterministic timestamps, * use nondeterministic random values, * use external network calls, * use mutable global state, * use cached results. S.4. Stage-by-Stage Deterministic Evaluation S4.1. Canonical Validation * Reconstruct canonical preimage. * Compute digest. * Compare digest to EnvelopeDigest. * Validate lineage semantics. * Record typed results. S4.2. Signature Verification * Verify signature over canonical preimage. * Record VALID or INVALID. S4.3. CAID Projection * Extract action. * Project CAID. * Record MATCH or MISMATCH. S4.4. AEC Evidence Evaluation * Load required evidence types. * Evaluate evidence deterministically. * Record SATISFIED, UNSATISFIED, or UNDEFINED. S4.5. AUTHZ Authority Evaluation * Evaluate authority under referenced policy. * Record AUTHORIZED, REFUSED, or UNDEFINED. S4.6. AEB Execution Semantics * Execute action only if AUTHORIZED. * Record BOUND, UPDATED, NOT_EXECUTED, or UNDEFINED. * Execution timestamps MUST be deterministic in test mode: "1970-01-01T00:00:00Z" S.5. Deterministic Transition Vector Assembly The harness MUST assemble: { sdlp_envelope | candidate_input, canonical_preimage, signature, caid, aec, authorization, aeb, [ failure_code ] } Rules: * All fields MUST appear. * Negative cases MUST include failure_code. * Positive cases MUST NOT include failure_code. * JSON keys MUST be lexicographically sorted. * CBOR maps MUST be deterministically sorted (RFC 8949). S.6. Expected Output Comparison The harness MUST compare: * each stage result, * each typed field, * each digest, * each CAID projection, * each evidence result, * each authority result, * each execution result, * the failure_code (if present), * the entire serialized transition vector. Comparison MUST be byte‑for‑byte. S.7. Negative Case Determinism Negative cases MUST: * produce deterministic failure codes, * record all stage results (even UNDEFINED), * preserve mutated candidate inputs exactly, * never omit fields. Negative cases MUST NOT: * infer missing fields, * normalize mutated fields, * modify submitted inputs. S.8. Test Harness Modes The harness MUST support: * strict mode — all mismatches cause failure, * diagnostic mode — mismatches are logged but not fatal, * replay mode — re‑evaluate stored transition vectors, * batch mode — evaluate entire test suite (Appendix H). All modes MUST be deterministic. S.9. Test Suite Integration The harness MUST be able to run: * all positive cases (Appendix A), * all negative cases (Appendices B–D), * full worked examples (Appendix F), * multi‑stage failures (Appendix K), * SCITT/EMILIA integration tests (Appendix M), * serialization tests (Appendix G), * compliance tests (Appendix R). S.10. Summary This deterministic test harness ensures: * reproducible results across implementations, * strict domain separation, * typed stage results, * immutable transition vectors, * deterministic serialization, * deterministic evaluation of all verification stages. The harness defines the complete interoperability boundary for verifying SDLP, CAID, AEC, AUTHZ, AEB, SCITT, and EMILIA systems. Appendix T. Formal Semantics of Failure Codes This appendix defines the formal semantics of failure codes used in negative transition vectors. Failure codes identify the primary expected failure under the trust root, authority policy, and verification chain defined in Section 6. They do not describe all failures; they describe the earliest and most fundamental failure. T.1. Purpose of Failure Codes Failure codes serve three purposes: 1. Identify the primary expected failure. 2. Provide a privacy‑neutral summary of the failure. 3. Enable deterministic negative‑case classification. Failure codes MUST NOT: * expose raw evidence, * expose identity information, * expose policy internals, * expose execution logs. T.2. Failure Code Vocabulary The interoperability profile defines the following failure codes: CANONICAL_MISMATCH SIG_INVALID CAID_MISMATCH AEC_UNSATISFIED AUTHZ_REFUSED AEB_PRECONDITION_FAILED MULTI_STAGE_FAILURE No other failure codes are permitted. T.3. Formal Semantics T3.1. CANONICAL_MISMATCH Meaning: The submitted envelope or candidate input does not match the canonical preimage. Conditions: * digest mismatch, or * lineage violation, or * timestamp violation, or * non‑canonical serialization. Priority: Highest. This failure supersedes all others. T3.2. SIG_INVALID Meaning: The signature does not authenticate the signer over the canonical preimage. Conditions: * invalid signature bytes, * wrong public key, * unsupported signature suite, * trust‑root mismatch. Priority: Second highest, after canonical mismatch. T3.3. CAID_MISMATCH Meaning: The submitted action does not correspond to the expected CAID. Conditions: * projection mismatch, * malformed action identifier, * unsupported action. Priority: Third highest. T3.4. AEC_UNSATISFIED Meaning: Required evidence is missing, invalid, or insufficient. Conditions: * missing enrollment proof, * wrong authority domain, * version too low, * revoked or stale evidence. Priority: Fourth highest. T3.5. AUTHZ_REFUSED Meaning: The signer is not authorized under the referenced authority policy. Conditions: * signer not enrolled, * policy mismatch, * credential invalid or revoked. Priority: Fifth highest. T3.6. AEB_PRECONDITION_FAILED Meaning: Execution is not permitted due to earlier failures. Conditions: * canonical mismatch, * signature invalid, * CAID mismatch, * evidence unsatisfied, * authorization refused. Priority: Sixth highest. T3.7. MULTI_STAGE_FAILURE Meaning: Multiple failures occurred, but none is clearly dominant under the trust root and authority policy. Conditions: * conflicting failure modes, * ambiguous primary failure, * simultaneous failures with equal priority. Priority: Lowest. Used only when no single failure dominates. T.4. Failure Code Selection Algorithm The verifier MUST select the failure code using the following deterministic algorithm: 1. If canonical_result == INVALID: failure_code = CANONICAL_MISMATCH 2. Else if signature.verification_result == INVALID: failure_code = SIG_INVALID 3. Else if caid.projection_result == MISMATCH: failure_code = CAID_MISMATCH 4. Else if aec.result == UNSATISFIED: failure_code = AEC_UNSATISFIED 5. Else if authorization.result == REFUSED: failure_code = AUTHZ_REFUSED 6. Else if aeb.execution_result == NOT_EXECUTED: failure_code = AEB_PRECONDITION_FAILED 7. Else: failure_code = MULTI_STAGE_FAILURE This algorithm MUST be applied exactly as written. T.5. Propagation Rules * Earlier failures propagate but do not halt the chain. * Later failures do not override earlier failures. * MULTI_STAGE_FAILURE is used only when no stage dominates. T.6. Privacy Rules Failure codes MUST NOT encode: * personal identifiers, * organizational identifiers, * evidence contents, * authority details, * execution logs. Failure codes MUST be privacy‑neutral. T.7. Determinism Requirements Failure code selection MUST be: * deterministic, * reproducible, * independent of external state, * independent of SCITT registration, * independent of EMILIA policy evaluation. T.8. Summary Failure codes provide a privacy‑neutral, deterministic summary of the primary expected failure. They do not describe all failures; they identify the earliest and most fundamental failure under the trust root and authority policy. The selection algorithm ensures consistent negative‑case classification across implementations. Appendix U. Interop Profile Glossary This appendix defines the glossary of terms used throughout this interoperability profile. Definitions are scoped to the profile and preserve strict domain separation (Appendix O). U.1. SDLP Terms SDLP (Secured Digital Lifecycle Protocol) The canonical object‑lifecycle protocol defining envelopes, lineage, lifecycle states, timestamps, and digest semantics. SDLP Envelope A canonical, deterministically serialized object containing: * DigitalID * Lineage * Lifecycle * Timestamp * BodyDigest * EnvelopeDigest Candidate Input A submitted object that resembles an SDLP envelope but is not guaranteed to be canonical. May contain mutated fields. Canonical Preimage The deterministic serialization of an SDLP envelope used for digest construction and signature verification. EnvelopeDigest SHA‑256 digest of the canonical preimage. Lineage A structure describing parent object and sequence number. U.2. Signature Terms Signature Suite The cryptographic algorithm used to sign the canonical preimage. Verification Result VALID or INVALID, indicating whether the signature authenticates the signer over the canonical preimage. Trust Root The authority domain or key hierarchy used to validate signatures. U.3. CAID Terms CAID (Canonical Action Identifier) A deterministic identifier describing the canonical identity of an action. Action The submitted operation (e.g., ownership-binding, lifecycle-update). CAID Projection The deterministic mapping from submitted action → CAID. Projection Result MATCH or MISMATCH. U.4. AEC Terms AEC (Authorization Evidence Chain) A typed set of evidence requirements needed to authorize an action. Evidence Type The category of evidence required (e.g., enrollment-proof). Authority Domain The domain responsible for issuing or validating evidence. Evidence Result SATISFIED, UNSATISFIED, or UNDEFINED. U.5. AUTHZ Terms Authority Reference A stable identifier for the authority policy used to evaluate authorization. Authorization Result AUTHORIZED, REFUSED, or UNDEFINED. U.6. AEB Terms AEB (Action Evidence Boundary) The execution semantics domain determining whether an action is executed and what result it produces. Execution Result BOUND, UPDATED, NOT_EXECUTED, or UNDEFINED. Execution Timestamp RFC 3339 timestamp recorded when an admitted action is executed. U.7. SCITT Terms SCITT (Secure Cryptographic Transparency Technology) A transparency service that records submitted statements and issues receipts. SCITT does not evaluate canonical SDLP semantics. SCITT Receipt A signed record containing: * registration_hash * timestamp * transparency_log identifier * receipt_signature Registration Hash Digest of the registered statement. U.8. EMILIA Terms EMILIA A policy evaluation engine that interprets transition vectors and SCITT receipts to produce transparency records. EMILIA does not recompute canonical SDLP semantics. EMILIA Transparency Record A typed, policy‑derived record describing: * action_class * evidence_state * authority_state * execution_state * transparency_state U.9. Transition Vector Terms Transition Vector A structured, immutable evidence artifact containing: * SDLP envelope or candidate input * canonical_preimage * signature block * CAID block * AEC block * AUTHZ block * AEB block * optional failure_code Typed Result A structured field describing the outcome of a verification stage. Failure Code A privacy‑neutral identifier describing the primary expected failure (Appendix T). U.10. Serialization Terms Deterministic Serialization A stable, reproducible encoding of objects (JSON or CBOR) with lexicographically sorted keys and no nondeterministic fields. Canonical Serialization The specific deterministic serialization rules defined in Appendix G. U.11. Domain Separation Terms Security Domain A logically isolated verification domain (SDLP, CAID, AEC, AUTHZ, AEB, SCITT, EMILIA). Domain Separation The rule that no domain may assert or override the semantics of another domain (Appendix O). U.12. Summary This glossary defines all terms used across the interoperability profile. Each definition is scoped to its domain and avoids semantic overlap. The glossary ensures consistent interpretation across SDLP, CAID, AEC, AUTHZ, AEB, SCITT, EMILIA, and transition vector systems. Appendix V. Worked End‑to‑End Lifecycle Example (All Domains) This appendix provides a complete, end‑to‑end lifecycle example of an SDLP object as it moves through all domains defined in this interoperability profile. The example illustrates strict domain separation, typed results, deterministic serialization, and the role of transition vectors as the interoperability boundary. V.1. Initial SDLP Object A canonical SDLP envelope is created: { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-500", "Lineage": { "parent": null, "sequence": 1 }, "Lifecycle": "active", "Timestamp": "2026-07-28T07:00:00Z", "BodyDigest": "sha256:abcd5000...", "EnvelopeDigest": "sha256:9988aabb5000..." } This envelope contains no evidence, no authority assertions, and no execution semantics. It is purely canonical SDLP. V.2. Submission to Verifier The envelope is submitted to a verifier. The verifier does not assume the envelope is canonical; it performs canonical validation first. V.3. Stage 1: Canonical SDLP Validation The verifier reconstructs the canonical preimage: "SDLPv1|did:sdlp:EXAMPLE-OBJECT-500|1|active|2026-07-28T07:00:00Z|abcd5000..." The digest matches the submitted EnvelopeDigest. { "canonical_validation": { "digest_match": "MATCH", "canonical_result": "VALID" } } V.4. Stage 2: Signature Verification The envelope includes a valid Ed25519 signature over the canonical preimage. { "signature": { "suite": "Ed25519", "public_key": "ed25519:authz-key-500", "signature": "sig:1122aabb5000...", "verification_result": "VALID" } } V.5. Stage 3: CAID Projection The submitted action is "ownership-binding". The verifier projects it to: "caid:ownership-binding:v1" { "caid": { "action": "ownership-binding", "projection": "caid:ownership-binding:v1", "projection_result": "MATCH" } } V.6. Stage 4: AEC Evidence Evaluation The action requires: { "evidence_type": "enrollment-proof", "authority_domain": "example.com", "min_version": 1 } The signer provides valid evidence. { "aec": { "required": { ... }, "result": "SATISFIED" } } V.7. Stage 5: AUTHZ Authority Evaluation The signer is authorized under: "authz:example.com:owner-binding-policy:v2" { "authorization": { "authority_reference": "authz:example.com:owner-binding-policy:v2", "result": "AUTHORIZED" } } V.8. Stage 6: AEB Execution Semantics The action is executed successfully. { "aeb": { "execution_result": "BOUND", "execution_timestamp": "2026-07-28T07:00:01Z" } } V.9. Transition Vector Assembly The verifier assembles the full transition vector: { "sdlp_envelope": { ...canonical envelope... }, "canonical_preimage": "SDLPv1|did:sdlp:EXAMPLE-OBJECT-500|1|active|2026-07-28T07:00:00Z|abcd5000...", "signature": { ...VALID... }, "caid": { ...MATCH... }, "aec": { ...SATISFIED... }, "authorization": { ...AUTHORIZED... }, "aeb": { "execution_result": "BOUND", "execution_timestamp": "2026-07-28T07:00:01Z" } } No failure_code is present because this is a positive case. V.10. SCITT Registration The transition vector is submitted to SCITT. SCITT records the statement and issues a receipt: { "scitt_receipt": { "registration_hash": "sha256:scitt-reg-500...", "timestamp": "2026-07-28T07:00:02Z", "transparency_log": "scitt.example.com/logs/main", "receipt_signature": "sig:scitt-signed-500..." } } SCITT does not evaluate canonical SDLP semantics, evidence, authority, or execution. V.11. EMILIA Ingestion EMILIA receives: * the transition vector, * the SCITT receipt. EMILIA evaluates policy: { "emilia_policy": { "action_class": "ownership-binding", "evidence_state": "SATISFIED", "authority_state": "AUTHORIZED", "execution_state": "BOUND", "transparency_state": "REGISTERED" } } V.12. EMILIA Transparency Record EMILIA produces a transparency record: { "emilia_transparency_record": { "DigitalID": "did:sdlp:EXAMPLE-OBJECT-500", "action": "ownership-binding", "admission": "ADMITTED", "execution": "BOUND", "scitt_receipt_hash": "sha256:scitt-reg-500..." } } V.13. End‑to‑End Summary This example demonstrates: * SDLP defines canonical identity. * CAID defines action identity. * AEC defines evidence requirements. * AUTHZ defines authority. * AEB defines execution semantics. * SCITT records registration. * EMILIA evaluates policy. The transition vector is the interoperability boundary connecting all domains without allowing any domain to override another. Appendix W. Formal Verification Chain State Machine This appendix defines the formal state machine for the multi‑stage verification chain described in Section 6. The state machine provides a precise operational semantics for SDLP canonical validation, CAID projection, AEC evidence evaluation, AUTHZ authority evaluation, and AEB execution semantics. W.1. State Machine Overview The verification chain is modeled as a deterministic finite state machine (FSM): M = (S, Σ, δ, s0, F) where: S = set of verification states Σ = set of inputs (submitted envelope or candidate input) δ = transition function s0 = initial state F = set of terminal states (positive or negative) The machine is strictly feed‑forward: no state may override the semantics of a previous state (Appendix O). W.2. State Definitions The state set S consists of: S0 = INITIAL S1 = CANONICAL_VALID S2 = CANONICAL_INVALID S3 = SIG_VALID S4 = SIG_INVALID S5 = CAID_MATCH S6 = CAID_MISMATCH S7 = AEC_SATISFIED S8 = AEC_UNSATISFIED S9 = AEC_UNDEFINED S10 = AUTHZ_AUTHORIZED S11 = AUTHZ_REFUSED S12 = AUTHZ_UNDEFINED S13 = AEB_EXECUTED S14 = AEB_NOT_EXECUTED S15 = AEB_UNDEFINED S16 = TERMINAL_POSITIVE S17 = TERMINAL_NEGATIVE All states are observable and MUST be recorded in the transition vector. W.3. Input Alphabet Σ Σ consists of: * canonical SDLP envelopes * mutated candidate inputs Inputs are immutable and deterministically serialized. W.4. Transition Function δ δ is defined as follows: W4.1. Canonical Validation δ(S0, envelope) = S1 if canonical(envelope) == VALID S2 otherwise W4.2. Signature Verification δ(S1, envelope) = S3 if signature(envelope) == VALID S4 otherwise δ(S2, envelope) = S4 ; canonical failure forces signature INVALID W4.3. CAID Projection δ(S3, envelope) = S5 if caid(envelope) == MATCH S6 otherwise δ(S4, envelope) = S6 ; signature failure forces CAID MISMATCH W4.4. AEC Evidence Evaluation δ(S5, envelope) = S7 if evidence == SATISFIED S8 if evidence == UNSATISFIED δ(S6, envelope) = S9 ; CAID mismatch → AEC UNDEFINED W4.5. AUTHZ Authority Evaluation δ(S7, envelope) = S10 if authorized == TRUE S11 if authorized == FALSE δ(S8, envelope) = S11 ; unsatisfied evidence → REFUSED δ(S9, envelope) = S12 ; AEC undefined → AUTHZ undefined W4.6. AEB Execution Semantics δ(S10, envelope) = S13 ; execute action δ(S11, envelope) = S14 ; not executed δ(S12, envelope) = S15 ; undefined W.5. Terminal States Terminal states are: F = { S16, S17 } W5.1. Positive Terminal State S13 → S16 ; execution succeeded W5.2. Negative Terminal State S14 → S17 ; execution not permitted S15 → S17 ; execution undefined W.6. Failure Code Selection Failure codes correspond to the earliest failure state: S2 → CANONICAL_MISMATCH S4 → SIG_INVALID S6 → CAID_MISMATCH S8 → AEC_UNSATISFIED S11 → AUTHZ_REFUSED S14 → AEB_PRECONDITION_FAILED S15 → MULTI_STAGE_FAILURE Positive terminal state S16 MUST NOT include a failure code. W.7. Determinism Properties The state machine is: * deterministic (no nondeterministic transitions), * total (every state has a defined successor), * acyclic (no loops), * strictly feed‑forward (no backward edges), * domain‑separated (no cross‑domain overrides). W.8. Formal Guarantees The state machine guarantees: * canonical SDLP semantics cannot be overridden, * signature validity cannot assert authority, * CAID projection cannot assert evidence, * evidence cannot assert canonical identity, * authority cannot assert execution, * SCITT and EMILIA cannot alter verification states. W.9. Summary This formal state machine defines the exact operational semantics of the verification chain. It ensures deterministic evaluation, strict domain separation, typed results, and consistent negative‑case classification across implementations. Appendix I. Transition Vector ABNF [CONTENT FROM APPENDIX I — UNMODIFIED] Appendix J. End‑to‑End Verifier Walkthrough [CONTENT FROM APPENDIX J — UNMODIFIED] Appendix K. Worked Multi‑Stage Failure Trace [CONTENT FROM APPENDIX K — UNMODIFIED] Appendix L. Verifier Pseudocode [CONTENT FROM APPENDIX L — UNMODIFIED] Appendix M. End‑to‑End SCITT/EMILIA Integration Example [CONTENT FROM APPENDIX M — UNMODIFIED] Appendix N. Transition Vector Storage & Retrieval Model [CONTENT FROM APPENDIX N — UNMODIFIED] Appendix O. Security Domain Separation Rationale [CONTENT FROM APPENDIX O — UNMODIFIED] Appendix P. Privacy & Minimization Considerations [CONTENT FROM APPENDIX P — UNMODIFIED] Appendix Q. Threat Model & Attack Surface [CONTENT FROM APPENDIX Q — UNMODIFIED] Appendix R. Interop Profile Compliance Checklist [CONTENT FROM APPENDIX R — UNMODIFIED] Appendix S. Deterministic Test Harness Specification [CONTENT FROM APPENDIX S — UNMODIFIED] Appendix T. Formal Semantics of Failure Codes [CONTENT FROM APPENDIX T — UNMODIFIED] Appendix U. Interop Profile Glossary [CONTENT FROM APPENDIX U — UNMODIFIED] Appendix V. Worked End‑to‑End Lifecycle Example (All Domains) [CONTENT FROM APPENDIX V — UNMODIFIED] Appendix W. Formal Verification Chain State Machine [CONTENT FROM APPENDIX W — UNMODIFIED] Authors' Addresses M. Norton Independent Protocol Architect El Mirage, Arizona, USA Email: mark433norton@gmail.com