Transparency Record Protocol for AI Governance

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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."¶

This Internet-Draft will expire on 4 June 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The rapid deployment of AI systems across critical infrastructure requires standardized mechanisms for transparency and accountability. Current approaches rely on application-specific logging that cannot be verified across organizational boundaries.¶

The Transparency Record Protocol (TRP) addresses this gap by providing:¶

• Cryptographically signed audit trails for AI decisions¶
• Zero-trust identity verification using X.509 PKI¶
• Network-boundary policy enforcement via inspection headers¶
• Extensible metadata for quality metrics and governance frameworks¶

TRP is designed to integrate with existing HTTP infrastructure through custom headers, requiring no changes to application payloads.¶

2. Conventions and Definitions

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.¶

3. Protocol Overview

TRP operates as an overlay protocol on HTTP/1.1 and HTTP/2. Each HTTP request carrying TRP metadata includes:¶

1. A compressed context header containing the full TRP record¶
2. An uncompressed inspection header for fast firewall decisions¶
3. A signature header containing the most recent cryptographic signature¶

Upon receiving a TRP-enabled request, a compliant service:¶

1. Validates the signature chain¶
2. Verifies entity identity against allow-lists¶
3. Checks security clearance compatibility¶
4. Enforces governance requirements¶
5. Appends its own processing step and signature¶
6. Forwards the updated record¶

4. Header Transport

TRP-compliant HTTP messages MUST include the following headers:¶

X-Transparency-Context: <base64-zstd-json>

X-Transparency-Protocol: TRP/1.1

X-Transparency-Signature: <base64-signature>

X-Transparency-Inspection: {"record_id":"...","security_level":"SECRET"}

5. Record Structure

The TRP record is a JSON object with the following top-level fields:¶

6. Signature Chain

TRP uses a cumulative signature chain to ensure tamper evidence. Each processing step appends a signature covering:¶

1. The hash of all previous content (SHA-256)¶
2. The current processing step data¶
3. A timestamp¶

The signature algorithm MUST be Ed25519 as specified in [RFC8032].¶

Signature verification MUST validate the entire chain from origin to the current step. Any invalid signature indicates tampering.¶

7. Policy Enforcement

TRP-compliant firewalls SHOULD implement the following checks:¶

8. Security Considerations

9. IANA Considerations

This document requests registration of the following HTTP headers:¶

• X-Transparency-Context¶
• X-Transparency-Protocol¶
• X-Transparency-Signature¶
• X-Transparency-Inspection¶
• X-Transparency-Rejection¶
• X-Transparency-Rejection-Reason¶
• X-Transparency-Rejection-Policy¶
• X-Transparency-Rejection-Details¶

Appendix A. ABNF Grammar

The following ABNF grammar defines the TRP header format:¶

TRP-Context-Header   = "X-Transparency-Context" ":" SP Base64-Value
TRP-Protocol-Header  = "X-Transparency-Protocol" ":" SP "TRP/" Version
TRP-Signature-Header = "X-Transparency-Signature" ":" SP Base64-Value
TRP-Inspection-Header = "X-Transparency-Inspection" ":" SP JSON-Object

Version      = 1*DIGIT "." 1*DIGIT
Base64-Value = 1*( ALPHA / DIGIT / "+" / "/" / "=" )
JSON-Object  = "{" *( JSON-Member ) "}"

Security-Level = "PUBLIC" / "INTERNAL" / "CONFIDENTIAL" /
                 "RESTRICTED"

DID                = "did:" Method ":" Method-Specific-ID
Method             = 1*ALPHA
Method-Specific-ID = 1*( ALPHA / DIGIT / "." / "-" / "_" / ":" )

Appendix B. Example Records

{
  "protocol": "TRP/1.1",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "started_at": "2025-12-17T14:30:00Z",
  "entity_context": {
    "organization": "did:web:example.gov",
    "service_id": "gateway",
    "certificate_chain": ["MIIB..."]
  },
  "security_context": {
    "domain": "COMMERCIAL",
    "level": "PUBLIC"
  },
  "signatures": []
}

Acknowledgments

The author would like to thank the AI governance and security communities for their input on this specification.¶

Author's Address