Verifiable AI Provenance Framework (VAP): An Architectural Framework for Auditable AI Decision Trails

Internet-Draft	VAP Framework	October 2026
Kamimura	Expires 27 April 2027	[Page]

Abstract

Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing provenance records that third parties can verify independently. Traditional logging approaches do not provide the cryptographic properties that regulatory examination, forensic investigation, and cross-organizational accountability depend on: detectability of alteration, detectability of omission after commitment, and attribution.¶

This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner.¶

VAP makes records auditable and attributable after the fact. It does not prevent, block, or intercept any system behaviour, and it does not warrant that any recorded decision was correct, fair, or safe. The detailed requirement set is maintained by the VeritasChain Standards Organization (VSO) as a separate specification; this document describes the architecture and its mapping to IETF work.¶

This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area.¶

1. Introduction

The deployment of automated decision-making systems across critical infrastructure has created an urgent need for provenance records that third parties can verify. These systems--including AI-driven trading algorithms, autonomous vehicle controllers, medical diagnostic systems, and public administration scoring systems--make decisions that significantly impact human welfare and require robust audit trails for regulatory oversight, forensic analysis, and accountability determination.¶

Current approaches to logging automated system behavior typically rely on traditional audit logs that lack the cryptographic properties necessary to serve as reliable evidence. While existing IETF technologies provide many of the necessary building blocks, there is no established architectural framework for applying these technologies consistently across different domains.¶

This document proposes a unifying framework that coordinates existing IETF security building blocks--specifically SCITT for transparency infrastructure, RATS for environment attestation, and COSE for cryptographic operations--to produce audit trails for high-impact AI and automated systems in which alteration, and omission after commitment, are detectable by third parties.¶

This document describes the Verifiable AI Provenance Framework (VAP), which aims to address this gap by defining architectural requirements for verifiable provenance while leveraging existing IETF work wherever possible.¶

VAP is positioned as a specialized audit and forensic layer focused on producing cryptographically verifiable decision trails. It is not intended to be a comprehensive AI governance protocol; rather, it addresses the specific problem of how to record and verify what decisions an automated system made, when, and based on what inputs. Broader governance concerns such as authorization policies, risk classification, and real-time approval workflows are outside VAP's scope but may consume VAP provenance data.¶

1.1. Why Traditional Logs Are Insufficient

Traditional logging mechanisms, including syslog [RFC5424], database audit trails, and application-level logs, suffer from several fundamental limitations when used as evidence of automated system behavior:¶

Mutability:: Log entries can be modified or deleted without detection, undermining their evidentiary value.¶
Ordering Uncertainty:: Without cryptographic chaining, the sequence of events cannot be independently verified; entries may be inserted, reordered, or removed.¶
No Completeness Proof:: Traditional logs provide no mechanism to prove that no entries have been omitted between any two recorded events.¶
Single-Party Control:: Logs typically reside under the sole control of the system operator, requiring auditors to trust the operator's integrity.¶
No Independent Verification:: Third parties cannot verify log integrity without trusting the log-producing entity.¶

These limitations make traditional logs weak evidence for regulatory examination, forensic reconstruction, or cross-organizational accountability determination. Whether any record is accepted as evidence is decided by the competent authority or court, not by the recording mechanism.¶

1.2. Cross-Sector Applicability

While particular implementations may focus on specific sectors, the underlying requirement for verifiable decision provenance is domain- agnostic. The same fundamental properties--non-repudiation, completeness verification, and independent auditability--are required across multiple sectors:¶

Financial Services:: Algorithmic trading systems subject to regulations such as MiFID II RTS 25 and SEC Rule 17a-4.¶
Healthcare:: AI diagnostic systems subject to FDA medical device regulations (21 CFR Part 11) and HIPAA requirements.¶
Transportation:: Autonomous vehicle systems requiring incident reconstruction capabilities per UN Regulation 157.¶
Public Administration:: Automated scoring and decision systems subject to administrative procedure requirements and GDPR Article 22 (automated individual decision-making).¶
Energy Infrastructure:: AI-driven grid management systems subject to critical infrastructure regulations including NIS2 Directive.¶

This cross-sector relevance motivates an architectural framework approach rather than domain-specific point solutions.¶

1.3. Regulatory Context

Several regulatory frameworks are creating immediate demand for technical standards addressing AI system auditability:¶

1.3.1. EU AI Act Article 12

Article 12 of the European Union's AI Act [EU-AI-ACT] requires high-risk AI systems to technically allow the automatic recording of events (logs) over the lifetime of the system. The logging capabilities are to enable the recording of events relevant to identifying situations that may result in a risk or a substantial modification, to post-market monitoring, and to monitoring of operation by deployers. For the remote biometric identification systems referred to in point 1(a) of Annex III, Article 12(3) lists minimum contents, including the identity of the natural persons involved in verifying the results.¶

Article 12 does not itself prescribe a storage technology or a cryptographic mechanism. Log retention periods are set elsewhere in the Regulation (for example, Articles 19 and 26).¶

Under Article 113 as amended by Regulation (EU) 2026/1744 [EU-2026-1744], Chapter III, Sections 1 to 3 (which include Article 12), with the exception of Article 6(5), apply from 2 December 2027 to AI systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 to those classified under Article 6(1) and Annex I. These dates are stated as of October 2026 and may change; readers should confirm them against the Official Journal.¶

No IETF RFC addresses these logging requirements directly. VAP describes how existing IETF building blocks can produce records relevant to such requirements, complementing the requirements work of ISO/IEC JTC 1/SC 42 and CEN-CENELEC JTC 21. Producing such records is not a determination of compliance with any law.¶

1.3.2. Other Regulatory Drivers

Additional regulatory frameworks creating demand for verifiable AI provenance include:¶

MiFID II RTS 25 (clock synchronisation for trading records)¶
SEC Rule 17a-4 (broker-dealer record retention)¶
NIST AI RMF 1.0 [NIST-AI-RMF] (AI risk management framework)¶
ISO/IEC 42001:2023 [ISO-42001] (AI management systems)¶
ISO/IEC 24970 (AI system logging; under development)¶

1.4. Scope of This Document

This document:¶

Describes the problem space and requirements for verifiable AI/automated system provenance¶
Proposes an architectural framework (VAP) for addressing these requirements¶
Maps VAP concepts to existing IETF technologies¶
Discusses the relationship between the framework and domain-specific profiles¶

This document does not:¶

Define new cryptographic primitives or protocols¶
Specify wire formats or APIs¶
Mandate particular implementations or deployment models¶
Address the verification of AI model correctness or fairness¶
Define comprehensive AI governance protocols (authorization, risk classification, approval workflows)¶

1.4.1. Relationship to Other IETF AI Work

It is important to distinguish VAP from other AI-related work in the IETF:¶

AIPREF (AI Preferences):: The AIPREF working group addresses how content owners express preferences about AI training data collection (e.g., robots.txt extensions). VAP does not address training data provenance; rather, it focuses on the runtime decision-making of deployed AI systems. AIPREF governs what data AI may learn from; VAP records what decisions AI systems make after deployment.¶
WIMSE (Workload Identity in Multi-System Environments):: The WIMSE working group addresses identity and authentication for workloads in cloud-native environments. VAP profiles may leverage WIMSE for AI agent identity management and signing key issuance, treating WIMSE as complementary infrastructure rather than overlapping scope.¶

1.5. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Note that this document primarily uses descriptive rather than normative language, as it describes an architectural framework rather than a protocol specification.¶

2. Problem Statement

This section describes the specific gaps in current approaches to automated system auditability that motivate the VAP framework.¶

2.1. Non-Repudiation Gaps

Non-repudiation requires that an entity cannot deny having performed an action. Current audit approaches often fail to provide this guarantee because:¶

Logs may not be cryptographically signed by the acting entity.¶
Signatures, when present, may use keys that are not adequately protected or attested.¶
The relationship between the signing key and the claimed identity may not be independently verifiable.¶

For automated systems, non-repudiation is particularly challenging because the "actor" may be an algorithm rather than a human, requiring clear identification of the specific system version, configuration, and operational parameters that produced a given decision.¶

The Entity Attestation Token (EAT) [RFC9711] provides a foundation for addressing these challenges through standardized claims for device and entity identification, software measurements, and freshness guarantees.¶

2.2. Integrity Without Completeness

Many existing approaches can demonstrate that individual log entries have not been modified (integrity), but cannot prove that no entries have been omitted (completeness). This gap is critical because:¶

An adversary can selectively delete unfavorable entries while preserving the integrity of remaining entries.¶
Auditors cannot distinguish between "no events occurred during period X" and "events were deleted from period X".¶
Regulatory requirements often mandate complete audit trails, not merely tamper-evident individual entries.¶

The Certificate Transparency model [RFC6962] demonstrated that completeness can be addressed through append-only logs with Merkle tree commitments, but this pattern has not been widely applied to automated system audit trails. See Appendix A for lessons learned.¶

Specifically, Merkle tree-based Receipts enable two critical proofs:¶

Inclusion Proof: Proves a specific record exists in the log at a given tree state.¶
Consistency Proof: Proves that a later tree state is an append-only extension of an earlier state--no records were removed or modified between the two states.¶

By requiring both proof types, VAP makes selective omission of records detectable once those records have been committed to the log. Sequential record identifiers (e.g., monotonic sequence numbers or UUID v7 timestamps) provide additional gap detection capability.¶

These mechanisms do not by themselves reveal a record that was never submitted. That such a record is missing is detectable only by reference to another record that implies its existence, such as a recorded request that a profile requires to terminate in a recorded outcome, or a corresponding record held by a counterparty. An event that was never measured, and that no record implies, remains outside the reach of any provenance mechanism.¶

2.3. Missing Responsibility Boundaries

Automated systems frequently operate across organizational boundaries, creating uncertainty about responsibility allocation:¶

An AI system may receive inputs from multiple external sources whose integrity cannot be independently verified.¶
Decisions may be influenced by models trained on data from various parties.¶
The chain of custody for decision inputs may span multiple organizations with different trust levels.¶

Current logging approaches typically capture only the local view of a single system, without cryptographic binding to the provenance of inputs or the responsibilities of other parties in the decision chain.¶

Note: RFC 9334 Errata 7314 identifies terminology ambiguities regarding entity and role definitions in multi-party scenarios. VAP profiles should carefully define responsibility boundaries with explicit reference to this errata when mapping to RATS concepts.¶

2.4. Inability to Independently Verify

Perhaps the most fundamental gap is that current approaches require trust in the log-producing entity. An auditor examining a traditional audit trail must trust that:¶

The logging system was correctly implemented.¶
The operator did not modify logs after the fact.¶
The presented logs represent the complete record.¶
Timestamps accurately reflect when events occurred.¶

This trust requirement is particularly problematic when the entity being audited has an incentive to present a favorable but inaccurate record, which is precisely when audit trails are most needed.¶

2.5. Summary of Gaps

The following table summarizes the gaps that VAP addresses:¶

Table 1: Summary of Gaps in Current Approaches
Gap	Traditional Approach	VAP Requirement
Non-repudiation	Trust-based	Cryptographic signatures with attested keys
Completeness	Not addressed	Merkle tree proofs
Cross-org accountability	Point-to-point	Verifiable chains
Independent verification	Trust operator	External anchoring

3. Design Goals

This section describes the high-level design goals that guide the VAP framework.¶

3.1. Verifiability Over Trust

The fundamental principle of VAP is "Verify, Don't Trust." Rather than requiring auditors to trust log-producing entities, VAP enables cryptographic verification of:¶

Individual record integrity (alteration of a committed record is detectable).¶
Batch completeness (omission, after anchoring, of records within an anchored batch is detectable).¶
Temporal ordering (the committed order of records can be verified).¶
Actor attribution (a record can be attributed to the holder of a signing key, at the granularity at which records are signed).¶

This shift from trust to verification is essential for audit scenarios where the audited entity may have incentives to present inaccurate records.¶

3.2. Cryptographic Completeness

VAP requires that completeness be verifiable at the granularity of anchored batches. This means:¶

Each anchored batch commitment binds at least the number of records, the first and last record identifiers, and the identifier of the policy under which the batch was produced, so that omission of records from that batch after anchoring, and presentation of different views of it, are detectable.¶
Gaps in the record sequence are detectable.¶
Historical states of the log can be reconstructed and verified.¶

This goes beyond traditional integrity (individual records are unmodified). It does not establish that every event that occurred was recorded. Completeness is verifiable only at anchor time and at batch granularity, and records that were never included in a batch are subject to the limits described in Section 2.2. Whether the expected set of records should be declared and committed in advance is an open question (Section 11.2).¶

3.3. Independent Verification

VAP should enable verification without requiring cooperation from the entity being audited. This requires:¶

External anchoring of commitments to independent third parties.¶
Standard formats that any verifier can process.¶
Public or shared verification infrastructure where appropriate.¶

3.4. Accountability Across Organizational Boundaries

Automated systems increasingly operate in environments where:¶

Inputs come from external parties whose integrity matters.¶
Outputs are consumed by downstream systems operated by others.¶
Multiple organizations may share responsibility for a decision.¶

VAP should support clear accountability boundaries by enabling:¶

Cryptographic binding of inputs to their sources.¶
Clear delineation of which entity is responsible for each assertion.¶
Verification that does not require trust in intermediate parties.¶

3.5. Domain Agnosticism

While particular applications of VAP may be domain-specific, the framework itself should be domain-agnostic:¶

Core concepts should apply across different sectors (finance, healthcare, transportation, etc.).¶
Domain-specific requirements should be addressed through profiles that extend the base framework.¶
The framework should not mandate domain-specific data formats or semantics.¶

This approach enables reuse of verification infrastructure across domains while allowing each domain to define its specific requirements.¶

4. VAP Architecture Overview

This section describes the conceptual architecture of VAP. This is an architectural framework, not a protocol specification; actual implementations would realize these concepts using specific technologies such as those described in Section 5.¶

4.1. Layered Architecture

VAP defines three conceptual layers:¶

Integrity Layer:: Provides tamper-evidence for individual records and the overall log structure. This layer addresses per-record integrity through cryptographic hashing, forward chaining to create append-only structure, periodic commitments (e.g., Merkle roots) for efficient verification, and external anchoring for independent verification.¶
Provenance Layer:: Captures the "what, when, who, why" of each decision. This layer defines actor identification (which system/model produced the decision), input provenance (what data informed the decision), decision context (parameters, constraints, environmental factors), and output characterization (what was decided/recommended/ executed).¶
Accountability Layer:: Enables responsibility assignment and cross-organizational verification. This layer provides responsibility boundaries between parties, verification interfaces for external auditors, evidence packaging for regulatory submission, and cross-reference capabilities for multi-party scenarios.¶

These layers are conceptual; actual implementations may combine them in various ways depending on deployment requirements.¶

4.2. Relationship Between Framework and Profiles

VAP is designed as a framework that supports domain-specific profiles. The framework defines:¶

Common requirements that apply across domains.¶
Mapping to underlying IETF technologies.¶
Extension points where profiles can add domain-specific requirements.¶

Profiles define:¶

Domain-specific event schemas.¶
Regulatory mapping for the specific domain.¶
Conformance requirements appropriate to the domain.¶
Any domain-specific extensions to the base framework.¶

This separation allows the framework to remain stable while profiles evolve to meet changing domain requirements.¶

4.3. Cryptographic Agility

VAP systems should support cryptographic agility, meaning the ability to:¶

Update cryptographic algorithms without protocol changes.¶
Support multiple algorithms during transition periods.¶
Clearly document the security properties provided by chosen algorithms.¶

This approach, often called "crypto-agility," is essential given the ongoing evolution of cryptographic best practices and the transition to post-quantum algorithms.¶

4.3.1. Post-Quantum Cryptography Considerations

NIST has standardized three post-quantum cryptographic algorithms in August 2024:¶

FIPS 203 [FIPS-203] (ML-KEM): Module-Lattice-Based Key-Encapsulation Mechanism¶
FIPS 204 [FIPS-204] (ML-DSA): Module-Lattice-Based Digital Signature Algorithm¶
FIPS 205 [FIPS-205] (SLH-DSA): Stateless Hash-Based Digital Signature Algorithm¶

For long-lived AI provenance records that may need to remain verifiable for decades, VAP profiles should consider post-quantum signature algorithms. [RFC9964] specifies ML-DSA for JOSE and COSE and registers:¶

ML-DSA-44 (COSE algorithm value -48): Security level 2¶
ML-DSA-65 (COSE algorithm value -49): Security level 3¶
ML-DSA-87 (COSE algorithm value -50): Security level 5¶

Profiles may mandate specific algorithms for interoperability within a domain, but should do so in a way that allows future algorithm updates.¶

5. Mapping to Existing IETF Work

A key principle of VAP is to leverage existing IETF technologies wherever possible rather than defining new protocols or formats. This section describes how VAP concepts map to ongoing IETF work.¶

        +--------------------+
        |        VAP         |   (Architectural Framework)
        | (This Document)    |
        +--------------------+
                 |
    +------------+------------+------------+
    |            |            |            |
    v            v            v            v
 +------+    +------+    +------+    +-------+
 | SCITT|    | RATS |    | COSE |    | WIMSE |  (IETF WGs)
 +------+    +------+    +------+    +-------+
    |            |            |            |
    v            v            v            v
 +------+    +------+    +------+    +-------+
 | CFRG |    | JOSE |    | etc. |    | SPICE |  (Supporting)
 +------+    +------+    +------+    +-------+

Figure 1: VAP Relationship to IETF Working Groups

5.1. SCITT (Supply Chain Integrity, Transparency and Trust)

The SCITT architecture, published as [RFC9943], provides the most direct mapping to VAP's Integrity Layer requirements.¶

5.1.1. Concept Mapping

Table 2: VAP to SCITT Concept Mapping
VAP Concept	SCITT Equivalent	Notes
Provenance Record	Signed Statement	COSE_Sign1 with CWT claims per RFC 9597
Append-Only Log	Transparency Service	Maintains ordered log via VDS
Merkle Commitment	Receipt	COSE Receipt per Merkle Tree Proofs
Verification Policy	Registration Policy	Admission criteria
External Anchor	Merkle Tree Root	Published via Signed Tree Head
Transparent Record	Transparent Statement	Statement + Receipt

5.1.2. SCITT Charter Scope Considerations

The SCITT WG charter explicitly scopes work to "software supply chain" and "firmware." However, the charter also notes that SCITT is "applicable to any other type of supply chain statements." VAP positions AI provenance as content-agnostic payload within SCITT's Signed Statements, which is explicitly supported by the architecture's design.¶

Profiles that wish to use SCITT infrastructure should:¶

Frame provenance records as supply chain statements about AI system behavior¶
Use standard SCITT Registration Policies for admission control¶
Leverage existing Transparency Service implementations where available¶

5.1.3. Key SCITT Terminology

VAP profiles using SCITT should adopt the following terminology from [RFC9943]:¶

Transparency Service: The service operating the append-only log¶
Signed Statement: A COSE_Sign1 signed object containing the provenance payload¶
Receipt: A COSE Receipt proving inclusion in the log¶
Transparent Statement: A Signed Statement combined with its Receipt¶
Registration Policy: Rules governing what statements are accepted¶
Verifiable Data Structure (VDS): The cryptographic structure (typically Merkle tree) underlying the log¶

5.1.4. External Anchor Requirements

SCITT provides tamper-evidence through Merkle tree commitments. In addition, the VSO specification of VAP requires, at every conformance level, external anchoring of signed batch roots: their publication to independent, external systems (e.g., RFC 3161 time-stamping authorities, transparency logs, public blockchains, or SCITT Transparency Services). It also requires an anchor continuity plan covering fallback targets and local retention of anchor records.¶

External Anchoring addresses a specific threat: a malicious Transparency Service operator who might attempt to rewrite history by reconstructing the entire log with altered content. Periodic anchoring of the Merkle root to external systems beyond the operator's control has the following effects:¶

Historical log states are committed to third-party systems¶
Any attempt to reconstruct a different history would produce Merkle roots inconsistent with previously anchored values¶
Regulators and auditors can detect retroactive alteration of anchored log states¶

This requirement emerged from domain profile experience (VCP) where the "Verify, Don't Trust" principle required that a verifier not depend on either the system operator or a single Transparency Service operator. External anchoring does not detect collusion among all parties that control the log and its anchors. Equivocation resistance also depends on the anchor target class: a time-stamping authority alone attests existence time, not uniqueness of the presented view. Profiles specify anchoring frequency (e.g., hourly, daily) based on domain-specific risk assessment, and the resulting completeness window must be disclosed when records are presented.¶

Producer-operated logs can also commit to their own history with signed checkpoints registered with one or more independent Transparency Services; [I-D.mih-scitt-checkpointed-local-log] specifies such a construction. Profiles may use comparable constructions to bind batch size and order to an independently registered commitment.¶

5.1.5. Alignment Approach

VAP profiles that address the Integrity Layer requirements should:¶

Encode provenance records as SCITT Signed Statements where applicable.¶
Include CWT Claims (COSE header parameter 15) with at minimum `iss` (issuer) and `sub` (subject) claims per [RFC9597].¶
Use SCITT Transparency Services for append-only log maintenance.¶
Leverage COSE Receipts per [RFC9942] for inclusion proofs, using the registered COSE header parameters: receipts (394), vds (395), and vdp (396).¶
Define Registration Policies appropriate to the domain.¶

This alignment allows VAP-conformant systems to benefit from the SCITT ecosystem, including existing Transparency Service implementations and verification tooling.¶

5.2. Remote Attestation Procedures (RATS)

The RATS working group [RFC9334] addresses the question of how to verify the state of a system producing attestations. This is relevant to VAP's Accountability Layer.¶

Per RFC 9334, the RATS architecture defines specific roles and data types: an Attester produces Evidence (claims about its own state), a Verifier evaluates that Evidence and produces an Attestation Result, and a Relying Party consumes the Attestation Result to make trust decisions. VAP's cross-organizational verification scenarios map naturally to this model.¶

5.2.1. Concept Mapping

Table 3: VAP to RATS Concept Mapping
VAP Concept	RATS Equivalent	Notes
Actor Attestation	Attester	Entity producing provenance records
Environment Binding	Evidence	Claims about Attester state
Cross-Org Verify	Verifier	Third-party verification svc
Verification Result	Attestation Result	Verifier output for Relying Party
Auditor/Regulator	Relying Party	Consumes results for trust decision

5.2.2. Entity Attestation Token (EAT)

The Entity Attestation Token specification [RFC9711] provides attestation-oriented claims particularly relevant to AI provenance:¶

Device/entity identification: `ueid`, `sueid` claims for unique AI model or inference endpoint identification¶
Software measurements: `manifests` and `measurements` claims for recording model hashes, weights, and dependencies¶
Composite systems: `submods` claim for representing ensemble models or ML pipelines¶
Freshness: `eat_nonce` ensuring non-replayable provenance records¶
Jurisdictional compliance: `location` claim for capturing inference geography (relevant to data sovereignty requirements)¶

5.2.3. Additional RATS Documents

VAP profiles requiring strong attestation should also consider:¶

Concise Reference Integrity Manifest (CoRIM) [I-D.ietf-rats-corim]: For model reference values¶
EAT Attestation Results [I-D.ietf-rats-ear]: Standardized format for attestation results¶
Attestation Results for Secure Interactions (AR4SI) [I-D.ietf-rats-ar4si]: Trustworthiness vectors¶

5.2.4. Alignment Approach

RATS concepts are particularly relevant when VAP systems need to attest to the integrity of the log-producing environment itself:¶

Entity Attestation Tokens (EAT) [RFC9711] can provide evidence about the execution environment.¶
Hardware-rooted attestation can strengthen claims about system integrity.¶
The RATS architecture provides a framework for reasoning about trust in the log-producing system.¶

VAP does not require RATS integration, but profiles may specify RATS usage for environments where stronger assurance about the log producer is needed.¶

5.3. COSE (CBOR Object Signing and Encryption)

COSE [RFC9052] provides the cryptographic message formats used by both SCITT and RATS. VAP systems that leverage these technologies will use COSE for:¶

Digital signatures on provenance records (COSE_Sign1).¶
CWT Claims in COSE headers per [RFC9597].¶
Receipts/inclusion proofs (COSE Receipts per [RFC9942]).¶
Encrypted payloads when confidentiality is required.¶
Algorithm identification and crypto-agility.¶

5.3.1. Alignment Approach

VAP profiles should:¶

Use COSE for all cryptographic operations where interoperability with SCITT/RATS is desired.¶
Follow COSE algorithm recommendations and deprecation guidance.¶
Leverage COSE's built-in algorithm agility for future migration, including transition to post-quantum algorithms per [RFC9964].¶

Profiles that need JSON-based formats may alternatively use JOSE [RFC7515] [RFC7516], though this limits interoperability with CBOR- based ecosystems.¶

5.4. CFRG (Crypto Forum Research Group)

The Crypto Forum Research Group (CFRG) provides cryptographic review and guidance that informs VAP's cryptographic requirements. Relevant CFRG work includes:¶

Guidance on hash function selection for Merkle trees.¶
Signature algorithm recommendations.¶
Post-quantum cryptography considerations.¶

VAP does not directly depend on CFRG outputs, but profiles should reference CFRG recommendations when selecting cryptographic algorithms.¶

5.5. WIMSE (Workload Identity in Multi-System Environments)

The WIMSE working group addresses identity and authentication for workloads (processes, containers, serverless functions) in cloud- native and multi-system environments. For VAP, WIMSE is relevant to the question of how AI systems obtain and manage the signing keys used to authenticate provenance records.¶

5.5.1. Relevance to AI Agent Identity

AI systems operating as autonomous agents require identity credentials to sign provenance records. WIMSE provides mechanisms for:¶

Workload identity issuance in containerized/cloud environments¶
Credential lifecycle management¶
Cross-organizational identity federation¶

The individual draft [I-D.ni-wimse-ai-agent-identity] specifically addresses AI agent identity within the WIMSE framework.¶

5.5.2. Alignment Approach

VAP does not define identity management mechanisms; instead, it assumes that actors (AI systems) possess valid signing credentials. Profiles may specify:¶

WIMSE as the identity infrastructure for cloud-native AI deployments¶
Integration points between WIMSE credential issuance and VAP signing requirements¶
Trust model considerations when AI agents operate across organizational boundaries¶

This separation of concerns allows VAP to focus on provenance structure and verification, while delegating identity management to specialized infrastructure like WIMSE.¶

5.6. Relationship Summary

The following table summarizes how VAP layers map to IETF work:¶

Table 4: VAP Layers to IETF Work Mapping
VAP Layer	Primary IETF Work	Supporting Work
Integrity Layer	SCITT	COSE, Merkle Tree Proofs, CT (RFC 6962/9162)
Provenance Layer	(Domain-specific profiles)	JSON Schema, CBOR, W3C VC 2.0 [W3C-VC-2.0], C2PA [C2PA-2.2]
Accountability Layer	RATS, EAT (RFC 9711)	WIMSE, CoRIM, AR4SI, OAuth/OIDC

VAP is explicitly designed to avoid duplicating existing IETF work. Where existing standards adequately address a requirement, VAP profiles should reference those standards rather than defining alternatives.¶

6. Why a Framework is Needed

Given that existing IETF technologies provide many of the necessary building blocks, one might ask whether a framework document is needed. This section explains the value of architectural coordination.¶

The challenge is not the absence of suitable technologies, but rather:¶

Ensuring consistent application of these technologies across domains.¶
Providing a reference architecture that profile developers can follow.¶
Identifying gaps that may require additional standardization.¶
Enabling interoperability between systems in different domains that need to exchange provenance information.¶

6.1. Risk of Fragmentation

Without architectural coordination, there is a risk that different domains will develop incompatible approaches to AI/automated system provenance:¶

Financial services might develop one approach.¶
Healthcare might develop another incompatible approach.¶
Automotive might develop yet another.¶

This fragmentation would:¶

Prevent reuse of verification infrastructure across domains.¶
Complicate cross-domain scenarios (e.g., AI systems that span finance and healthcare).¶
Increase implementation costs by requiring domain-specific tools.¶
Create confusion about what "verifiable provenance" means in different contexts.¶

A framework document can help reduce this fragmentation by establishing common vocabulary, requirements, and architectural patterns.¶

6.2. Profiles Alone Are Insufficient

One alternative to a framework would be to develop domain-specific profiles directly, without an overarching framework. This approach has drawbacks:¶

Each profile would need to independently define common concepts.¶
There would be no reference for ensuring profiles are compatible.¶
Common security considerations would be repeated across profiles.¶
It would be unclear how to develop profiles for new domains.¶

A framework provides a foundation that profile developers can build upon, ensuring consistency while allowing domain-specific customization.¶

6.3. Architectural Coordination Role

The value of VAP as a framework lies in its coordination role:¶

Defining common requirements that all profiles should meet.¶
Mapping those requirements to existing IETF technologies.¶
Providing guidance on how to develop compliant profiles.¶
Identifying areas where existing standards may be insufficient.¶
Enabling discussion of cross-domain interoperability requirements.¶

This coordination role does not require VAP to define new protocols; rather, it provides the architectural context within which existing protocols are applied.¶

6.4. Relationship to Other AI Governance Work

VAP is specifically focused on verifiable decision trails-- the problem of recording and verifying what decisions were made. It is not intended to address the full scope of AI governance, which includes concerns such as:¶

Risk-based authorization and approval workflows¶
Real-time governance decisions¶
AI model evaluation and certification¶
Federated governance authority networks¶

Other work addressing broader AI governance concerns may consume VAP provenance data as an input to governance decisions. VAP provides the after-the-fact verification layer that such systems can build upon.¶

6.5. VAP as Bridge Between Static and Runtime Verification

Examining the existing IETF landscape reveals a gap that VAP addresses:¶

SCITT (Supply Chain):: Excels at tracking static artifacts--built binaries, signed firmware, software bills of materials. It answers: "Was this the correct, untampered software?"¶
RATS (Attestation):: Excels at capturing point-in-time system state--hardware configuration, OS integrity, TEE status. It answers: "Was the execution environment trustworthy at this moment?"¶
VAP (Decision Provenance):: Captures the dynamic decisions made by verified software in verified environments. It answers: "What did the system actually decide, and can we prove it?"¶

The unique value of VAP lies in connecting these domains:¶

A SCITT-verified AI model binary...¶
...running in a RATS-attested trusted environment...¶
...produces decisions that VAP records as tamper-evident, attributable provenance.¶

This "missing link" perspective explains why VAP warrants architectural coordination: it bridges two established IETF work streams to address a problem (dynamic decision accountability) that neither fully covers alone.¶

7. Relationship to Domain-Specific Profiles

VAP is designed to support domain-specific profiles that tailor the framework to particular use cases. This section describes how profiles relate to the framework, using existing work as an example.¶

7.1. Example: Financial Trading (VCP)

The VeritasChain Protocol (VCP) [I-D.kamimura-scitt-vcp] is a profile of VAP focused on AI-driven algorithmic trading systems, and the only member of the VAP family that defines a wire protocol. VCP demonstrates how a profile specializes the framework. In the VSO specification of VAP, the compatibility of VCP v1.2 with VAP v1.2 is recorded as under integrity-alignment review: full conformance has not been established, and a clause-level conformance mapping is outstanding.¶

7.2. Current Profiles and Capabilities

VSO maintains a registry of VAP profiles and cross-cutting capabilities in its specification of VAP [VAP-SPEC]. At the time of writing it records the following. The registry, not this summary, is authoritative.¶

Table 5: VAP Profiles and Capabilities Recorded by VSO
Identifier	Scope	Status
VCP	Finance and algorithmic trading	v1.2 Released
CAP	Content and creative AI	v1.0 Released
CPP	Capture provenance	v1.4 Released
OAP	Observed artifact provenance	v0.1.1 Working Draft
MAP	Medical and healthcare AI	v0.1.2 Working Draft
PAP	Public sector	Partial Draft (Track B v0.2.0)
IAP	Industry accountability	Announced
DVP, AAP, EIP	Automotive, aviation, energy	Planned
DAP (capability)	Delegated access provenance	v0.1.0 Working Draft
SMP (capability)	Self-modification provenance	v0.2.0 Working Draft

For the Released profiles other than VCP, a conformance mapping to VAP v1.2 is outstanding, and neither CAP v1.0 nor CPP v1.4 is described as VAP v1.2 conformant. Related individual Internet-Drafts describe the refusal-event mechanism of CAP [I-D.kamimura-scitt-refusal-events] and the CPP core [I-D.vso-cpp-core]. Documents that describe VAP or propose VAP profiles outside VSO change control are not VSO profiles and confer no status on those profiles.¶

7.3. Potential Future Profiles

The framework is designed to accommodate profiles for further domain requirements, for example autonomous vehicles (incident reconstruction and liability determination) and energy infrastructure (critical infrastructure protection). Each profile would define domain-specific event schemas, conformance requirements, and regulatory mappings while adhering to the common framework requirements.¶

7.4. Profile Independence

It is important to emphasize that:¶

VAP does not depend on any particular profile.¶
Profiles are developed independently by domain experts.¶
A domain can adopt VAP without implementing profiles for other domains.¶
The framework is complete without reference to any specific profile.¶

The mention of VCP or other potential profiles in this document is illustrative only. VAP's value lies in providing architectural coordination, not in mandating any particular domain application.¶

8. Security Considerations

As an architectural framework rather than a protocol specification, VAP's security considerations are primarily about ensuring that profiles and implementations address the relevant threats. This section describes the threat model and explicit non-goals.¶

8.1. Threat Model Overview

VAP addresses threats from entities who might seek to:¶

8.1.1. Falsify Historical Records

An operator might attempt to modify, delete, or fabricate historical records to conceal problematic behavior or create false evidence. VAP addresses this through:¶

Cryptographic chaining that makes modification detectable.¶
External anchoring that makes history rewriting detectable.¶
Independent verification that does not require operator cooperation.¶

8.1.2. Omit Unfavorable Records

An operator might attempt to selectively omit records that reveal problematic behavior while preserving favorable records. VAP addresses this through:¶

Detection of omission after commitment via Merkle consistency proofs and anchored batch bindings.¶
Sequence numbering that reveals gaps.¶
External commitments that establish log state at specific times.¶

An operator that never records an event, and leaves no other record implying it, is not detected by these mechanisms (see Section 2.2).¶

8.1.3. Misattribute Actions

An operator might attempt to attribute actions to a different actor (algorithm, operator, or external party) than the one actually responsible. VAP addresses this through:¶

Digital signatures binding actions to specific actors.¶
Identity verification through established PKI or attestation mechanisms.¶
Clear provenance chains for multi-party scenarios.¶

8.1.4. Manipulate Timing

An operator might attempt to manipulate timestamps to change the apparent sequence of events. VAP addresses this through:¶

Cryptographic chaining that establishes relative ordering.¶
External anchoring that establishes absolute time bounds.¶
Trusted timestamping services where stronger time assurance is needed.¶

8.2. Explicit Non-Goals

VAP does not address certain security concerns that are outside its scope:¶

AI Model Security:: VAP records what decisions were made, not whether those decisions were correct or whether the AI model is secure against adversarial attacks.¶
Input Validation:: VAP can record what inputs were received, but does not validate whether inputs were legitimate or malicious.¶
Confidentiality:: While profiles may address confidentiality, the framework focuses on integrity and verifiability rather than confidentiality. Profiles must address confidentiality requirements specific to their domain.¶
Real-Time Detection and Prevention:: VAP provides forensic and audit capabilities after the fact. It does not prevent, block, or intercept system behaviour, and it does not provide real-time anomaly detection or intrusion prevention. Real-time monitoring systems may use VAP data, but such systems are outside VAP's scope.¶
Correctness of Recorded Content:: Detecting alteration after recording says nothing about whether a record was accurate when it was written. A record made by the acting system about itself and a record made by an independent observer are different kinds of evidence, and profiles should distinguish them.¶

8.3. Privacy Considerations

VAP provenance records may contain sensitive information about:¶

Business activities (e.g., trading strategies)¶
Personal data (e.g., in healthcare applications)¶
Critical infrastructure operations¶

Profiles must address privacy requirements specific to their domain, which may include:¶

Encryption of sensitive payload data.¶
Access controls on Transparency Service queries.¶
Crypto-shredding mechanisms for data subject to deletion rights (e.g., GDPR Article 17). This technique, corresponding to Cryptographic Erasure (CE) as described in NIST SP 800-88 Rev. 1 [NIST-SP-800-88], enables effective data deletion by destroying encryption keys rather than the encrypted data.¶
Selective disclosure mechanisms that reveal only necessary information.¶

8.3.1. Reconciling Append-Only Logs with Deletion Rights

A fundamental tension exists between append-only transparency logs (where deletion of committed entries is detectable) and regulatory requirements for data deletion (e.g., GDPR Article 17 "right to erasure"). Profiles addressing domains with deletion requirements should consider:¶

Off-chain data storage: Register only cryptographic hashes of sensitive payloads in the Transparency Service, storing actual data in separate systems where deletion is possible. This "hash-only registration" approach preserves verifiability-- anyone with the original data can verify it matches the registered hash--while keeping sensitive content out of the append-only log. Hashes of low-entropy data can be confirmed by guessing; salted commitments or encryption are needed for such data.¶
Encryption with key management: Encrypt sensitive payload data before registration; deletion is achieved by destroying the encryption keys (crypto-shredding).¶
Architectural separation: Design systems such that provenance metadata (which may need long-term retention) is separated from personal data (which may require deletion).¶
Redacted proofs: For profiles requiring selective disclosure, consider cryptographic techniques (e.g., hash trees with selective revelation) that allow proving specific claims without revealing the complete record.¶

The framework itself does not mandate specific privacy mechanisms, but requires that profiles clearly document how privacy requirements are addressed.¶

11. Next Steps

This document is intended to facilitate discussion about whether architectural coordination work is needed in the area of AI/automated system provenance.¶

11.1. Discussion Path

The author proposes the following discussion path:¶

Present this document for discussion at SecDispatch to determine the appropriate venue for further work.¶
Solicit feedback from the SCITT and RATS working groups on the proposed mappings to their work.¶
Gather input from domain experts on whether the framework adequately addresses their requirements.¶
Based on feedback, determine whether this work should proceed as individual submissions building on existing WGs (likely SCITT given closest alignment), be considered for a new focused work item, or be deferred pending additional implementation experience.¶

Discussion is not tied to any regulatory deadline. Application dates of the EU AI Act are summarized in Section 1.3.1.¶

11.2. Potential Future Work

Depending on community interest, future work might include:¶

Development of additional domain-specific profiles.¶
Specification of interoperability requirements between profiles.¶
Definition of common verification tooling requirements.¶
Guidance on relating profiles to regulatory recordkeeping provisions, without determining compliance.¶
Policy Identification mechanisms: Each domain profile may need to identify which operational policy or regulatory requirement governs a particular provenance record. This aligns with SCITT's Registration Policy concept and lets a verifier check automatically which declared policy a record cites. Future work could standardize policy identifier formats and registration procedures.¶
Declared scope and advance commitment: whether the expected set of records, or the rule that derives it, should be declared and committed before the activity it covers, and how a verifier should report fulfillment separately from cryptographic integrity, including an explicit indeterminate result. VSO has published an unadopted discussion draft and research verifier on this question; neither is part of the VAP requirement set.¶
A common, profile-independent Evidence Pack container. The VSO specification currently leaves the Evidence Pack format to profiles.¶

This document does not presuppose any particular outcome; it is intended to frame the problem and facilitate informed discussion.¶

12. References

12.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052]: Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/info/rfc9052>.
[RFC9334]: Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9597]: Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/info/rfc9597>.
[RFC9711]: Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/info/rfc9711>.

12.2. Informative References

[RFC5424]: Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.
[RFC6962]: Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC7515]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516]: Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC9162]: Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC7942]: Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.
[RFC9942]: Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/info/rfc9942>.
[RFC9943]: Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/info/rfc9943>.
[RFC9964]: Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, <https://www.rfc-editor.org/info/rfc9964>.
[I-D.mih-scitt-checkpointed-local-log]: Mih, S., "The Checkpointed Local Log (CLL)", Work in Progress, Internet-Draft, draft-mih-scitt-checkpointed-local-log-02, 14 October 2026, <https://datatracker.ietf.org/doc/html/draft-mih-scitt-checkpointed-local-log-02>.
[I-D.ietf-rats-ear]: Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT Attestation Results", Work in Progress, Internet-Draft, draft-ietf-rats-ear-04, 26 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ear-04>.
[I-D.kamimura-scitt-refusal-events]: Kamimura, T., "Verifiable AI Refusal Events using SCITT", Work in Progress, Internet-Draft, draft-kamimura-scitt-refusal-events-04, October 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-refusal-events-04>.
[I-D.vso-cpp-core]: Kamimura, T., "Capture Provenance Profile (CPP) Core", Work in Progress, Internet-Draft, draft-vso-cpp-core-04, October 2026, <https://datatracker.ietf.org/doc/html/draft-vso-cpp-core-04>.
[I-D.ietf-rats-corim]: Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and W. Pan, "Concise Reference Integrity Manifest", Work in Progress, Internet-Draft, draft-ietf-rats-corim, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim>.
[I-D.ietf-rats-ar4si]: Voit, E., Lu, H., Gonzalez Sanchez, I., and A. Fongen, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si>.
[I-D.kamimura-scitt-vcp]: Kamimura, T., "A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP)", Work in Progress, Internet-Draft, draft-kamimura-scitt-vcp-04, October 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-vcp-04>.
[I-D.ni-wimse-ai-agent-identity]: Yuan, N., Liu, P. C., and M. Richardson, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent-identity-03, 30 September 2026, <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-03>.
[EU-AI-ACT]: European Parliament and Council, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), as amended", Official Journal of the European Union L 1689, July 2024.
[EU-2026-1744]: European Parliament and Council, "Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 (Digital Omnibus on AI)", Official Journal of the European Union L, 2026/1744, July 2026, <https://eur-lex.europa.eu/eli/reg/2026/1744/oj>.
[VAP-SPEC]: VeritasChain Standards Organization, "Verifiable AI Provenance Framework (VAP) Framework Specification v1.2.0, Draft 3", VSO VSO-VAP-SPEC-001, October 2026, <https://github.com/veritaschain/vap-spec/blob/b5ef9316717bebe638d5eca621327b54cdda93e1/spec/v1.2/VAP_Framework_Specification.md>. Draft specification maintained by VSO; it has no standing in the IETF or any other established standards body.
[FIPS-203]: National Institute of Standards and Technology (NIST), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024, <https://csrc.nist.gov/pubs/fips/203/final>.
[FIPS-204]: National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS 204, August 2024, <https://csrc.nist.gov/pubs/fips/204/final>.
[FIPS-205]: National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS 205, August 2024, <https://csrc.nist.gov/pubs/fips/205/final>.
[NIST-AI-RMF]: National Institute of Standards and Technology (NIST), "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1, January 2023, <https://doi.org/10.6028/NIST.AI.100-1>.
[NIST-SP-800-88]: National Institute of Standards and Technology (NIST), "Guidelines for Media Sanitization", NIST SP 800-88 Rev. 1, December 2014, <https://doi.org/10.6028/NIST.SP.800-88r1>.
[ISO-42001]: International Organization for Standardization, "Information technology - Artificial intelligence - Management system", ISO/IEC 42001:2023, December 2023.
[W3C-VC-2.0]: Sporny, M., Longley, D., Chadwick, D., and O. Steele, "Verifiable Credentials Data Model v2.0", W3C Recommendation, May 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.
[C2PA-2.2]: Coalition for Content Provenance and Authenticity, "C2PA Technical Specification 2.2", May 2025, <https://c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html>.