Network Working Group B. Laurie Internet-Draft T. Santoro Intended status: Informational P. Anthonysamy Expires: 5 December 2026 S. de Haas A. Mathur Google LLC 3 June 2026 A Standard for Claiming Transparency and Falsifiability draft-laurie-tmif-01 Abstract This document specifies a Transparency Metadata Interchange Format (TMIF) that allows a system to make standardized, verifiable claims about its levels of transparency and falsifiability. TMIF is designed to be agnostic to specific threat models or mitigations, serving purely as a communication vehicle for system providers to declare how their security and privacy controls can be verified by third-party evaluators. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-laurie-tmif/. 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 5 December 2026. Laurie, et al. Expires 5 December 2026 [Page 1] Internet-Draft TMIF June 2026 Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2.1. System Component Definitions . . . . . . . . . . . . . . 4 3. Falsifiability of Privacy Claims . . . . . . . . . . . . . . 6 3.1. Transparency Levels . . . . . . . . . . . . . . . . . . . 7 4. Transparency Metadata Interchange Format (TMIF) . . . . . . . 7 4.1. Example TMIF Document . . . . . . . . . . . . . . . . . . 8 4.1.1. TMIF Field Definitions . . . . . . . . . . . . . . . 9 4.2. Usage of Transparency Metadata . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. Claim Tampering and Integrity Protection . . . . . . . . 10 5.2. Replay Attack Mitigations . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction As AI powered consumer facing features proliferate, AI experiences are leveraging increasing amounts of sensitive data to provide greater utility. This begs the question of how to assure the user around data privacy and how their data is processed by the AI. Along with users; regulators, device manufacturers and the larger ecosystem are all looking for ways to increase transparency around AI models. Privacy preserving systems give service providers a way to make strong claims about how data is handled, and users a way to independently verify those claims. Transparency approaches can, however, use different approaches, therefore some consistency in definitions and terminology is required in order to allow end users Laurie, et al. Expires 5 December 2026 [Page 2] Internet-Draft TMIF June 2026 (or their delegates) to examine these systems in detail and assess the overall veracity of the claims they make. This document therefore defines a Transparency Metadata Interchange Format (TMIF) for describing how transparency is achieved by such a system, in order to effectively allow evaluators to determine the overall level of transparency that the system can claim. TMIF is an agnostic standard for communicating the levels of transparency achieved by a system's components. Crucially, TMIF separates the _communication_ of transparency from the _evaluation_ of threats and mitigations. It does not prescribe specific threat models (e.g., STRIDE) or scoring weights. Instead, it provides a standardized JSON structure for system providers to list mitigated threats (via standard URNs), describe the applied mitigations, and declare the transparency level (the verifiable "proof") of those mitigations. Evaluators, researchers, and other 3rd parties can then use these TMIF documents as inputs for their own qualitative or quantitative assessments. A high degree of transparency means that end consumers, or their delegates, can assure themselves and have higher confidence around a service provider's claims about the usage and handling of their data. It is also possible to incentivize third parties and evaluators to focus their efforts towards finding falsifying examples of privacy and security claims. While this setup bears significant relation to [I-D.ietf-rats-ar4si], this draft focuses specifically on communicating about this transparency property. +-------------------+ +--------------------+ | System Provider |----(TMIF)-->| Third-Party | | (Claims Engine) | | Evaluator | +-------------------+ +--------------------+ | | (Attestation Evidence) (Verifies Proofs) v v +-------------------+ +--------------------+ | Hardware TEE | | Root of Trust | +-------------------+ +--------------------+ Laurie, et al. Expires 5 December 2026 [Page 3] Internet-Draft TMIF June 2026 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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. System Component Definitions A system that is set up to provide transparency and falsifiability will generally include the following components, which may have details specified in the TMIF: Accelerators When a TEE offloads computation to a hardware accelerator (e.g., a GPU, NPU), then in general the entire data pathway will be secured. This implies a mutually authenticated and encrypted channel between the host CPU's TEE and a TEE within the accelerator itself. The accelerator would also have its own capacity for secure processing and attestation. The TMIF format should be able to describe all of these implementation details. Attester The entity (comprising both hardware and software elements) that creates _Evidence_ about its state, configuration, or environment. It exposes this cryptographically bound data to prove its trustworthiness to a remote peer. For example, in a mobile application context, the handset's hardware-isolated Secure Element or Trusted Execution Environment (TEE) acts as the Attester to generate secure cryptographic proofs. Attestation Results A structured, cryptographically signed statement emitted by a Verifier after evaluating an Attester's Evidence. Attestation Results convey the Verifier's formal appraisal of the Attester's security posture and trustworthiness, enabling a Relying Party to make safe, risk-based decisions about whether to trust the Attester with sensitive data. Claimant The entity (such as a device OEM or service provider) generating the TMIF document to assert the transparency of their system. Client The device (e.g., a smartphone, laptop, or web browser) used to interact with the service. Includes software and hardware. Evaluator A third party (such as the App Defense Alliance) that ingests the TMIF document, verifies the artifacts, and applies their own threat modeling and scoring methodologies to approve or deny the system. Laurie, et al. Expires 5 December 2026 [Page 4] Internet-Draft TMIF June 2026 Evidence A set of claims about an Attester's state, configuration, or execution environment that is cryptographically bound and signed by the Attester. Evidence is intended to be consumed by a Verifier, which evaluates its authenticity and structural integrity to determine whether the Attester can be considered trustworthy. Falsifiability The design property ensuring that any accidental bug or malicious subversion of a system's stated privacy or security claims inherits a high risk of independent discovery. A claim is highly falsifiable if an evaluator can readily devise and execute tests to find definitive counterexamples to it. Isolation TEE environments provide memory protection, even from software with higher privilege. Remote attestation As per RATS Architecture [RFC9334], remote attestation consists of an interaction wherein an attester presents evidence about itself to enable a remote peer to decide whether or not to consider the attester trustworthy or not. Relying Party The entity that ultimately consumes the Attestation Results from the Verifier to make an informed, risk-based decision. In this architecture, the Relying Party depends on these verified results to determine whether or not to trust the Attester with sensitive data, allow access to enterprise services, or execute specific application logic (such as processing protected user data in plaintext). Server The machine that serves user requests. In a distributed system, this includes all machines that have access to the data. Service Operator The entity that operates the service. This entity processes the data and considered an untrusted party in the security model, as the goal is to constrain access to user data in plaintext. Service Provider The entity that develops, and deploys the service. This entity defines data processing logic and is considered an untrusted party in the security model, as the goal is to constrain access to user data in plaintext. TEE A hardware-isolated secure processing environment that protects the confidentiality and integrity of code and data executing within it, and can produce attestations about the state of the secured environment. Laurie, et al. Expires 5 December 2026 [Page 5] Internet-Draft TMIF June 2026 For the purposes of this standard, we define a TEE as a secure area that keeps code and data loaded inside it, usually a hardware TEE as mentioned above. Code and data in TEEs are protected by confidentiality and integrity: data confidentiality prevents unauthorized entities from outside the TEE from reading data, while code integrity prevents code in the TEE from being replaced or modified by unauthorized entities. Crucially, an unauthorized entity can include the owner/maintainer of the code and data inside the TEE. TEE Manufacturer The hardware vendor that designs and manufactures the processor containing the TEE. Transparency The property of a system configuration, source code, or binary execution environment being inspectable, and verifiable by external parties. In TMIF, transparency is quantified by a tiered level system (1-5) representing the robustness of the available technical proof. Trusted Computing Base As per the National Institute of Standards and Technology [NIST-TCB], we consider a trusted computing base to encompass the totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination responsible for enforcing a privacy policy. For the purposes of this document, transparency efforts will generally pertain only to the trusted computing base. All other components of a system do not need to be transparent in order for an evaluator to be able to assess a system's privacy and security claims. Verifier A trusted core component that ingests the _Evidence_ generated by the Attester. It validates the cryptographic authenticity of the claims (checking signatures, certificates, and roots of trust) and evaluates them against specific appraisal policies. The Verifier then outputs an appraisal result, known as _Attestation Results_, which is a structured, trusted statement about the Attester's security posture. 3. Falsifiability of Privacy Claims The aim of specifying the transparency metadata for a given system's components is to allow evaluators to assess the level of falsifiability of the system. A fully transparent system is designed in such a way to ensure that an accidental or malicious attempt to undermine privacy and security claims cannot be introduced without a risk of discovery. This is based on the principle that testing may show the presence of bugs or backdoors, but never their absence. The higher the falsifiability of a claim, the more likely it is for Laurie, et al. Expires 5 December 2026 [Page 6] Internet-Draft TMIF June 2026 someone to find a counterexample to it, in the event that claim were in fact false (e.g. because a bug or backdoor were introduced, accidentally or intentionally). In practice, a high degree of falsifiability also makes it difficult for an insider with highly privileged access to purposely subvert the claims of the system without risking discovery in doing so. The chief criterion for inclusion of metadata in the algorithmic calculation of levels is its role in supporting claims that increase falsifiability. 3.1. Transparency Levels We expect that evaluators will assess the claimant's mitigations based on the level of "proof" provided. The following standardized transparency levels define the tiers of falsifiability: +=======+=========+==========================================+ | Level | Name | Technical Evidence Requirement | +=======+=========+==========================================+ | 1 | Level 1 | Binary is publicly available. | +-------+---------+------------------------------------------+ | 2 | Level 2 | Level 1 features + binary is executable. | +-------+---------+------------------------------------------+ | 3 | Level 3 | Source code is publicly available. | +-------+---------+------------------------------------------+ | 4 | Level 4 | Level 3 features + code is reproducibly | | | | buildable. | +-------+---------+------------------------------------------+ | 5 | Level 5 | Formal proof of security properties is | | | | available. | +-------+---------+------------------------------------------+ Table 1: Standardized Transparency Levels 4. Transparency Metadata Interchange Format (TMIF) The Transparency Metadata Interchange Format is a JSON-based schema designed to communicate a system's composition, the claims it makes against standardized threats, the mitigations implemented, and the transparency level of those mitigations. To support complex architectures, TMIF documents catalog claims at the *component* level, but enforce an aggregate *system-wide transparency lower bound* (representing the "weakest link" of the system as a whole). Laurie, et al. Expires 5 December 2026 [Page 7] Internet-Draft TMIF June 2026 A system claiming compliance with this framework MUST expose a verifiable Transparency Metadata Interchange Format (TMIF) record. Evaluators SHOULD be able to cryptographically verify these claims without out-of-band protocols. 4.1. Example TMIF Document This section provides a sample TMIF document illustrating the component and claim structure. { "system_identifier": "urn:example:system:paic-compute-v1", "system_version": "1.0.0", "valid_until": "2026-12-31T23:59:59Z", "transparency_level_lower_bound": 2, "components": [ { "component_identifier": "urn:example:component:inference-node", "component_version": "1.0.0", "claims": [ { "threat_identifier": "urn:ada:threat:information-disclosure:data-in-transit", "mitigation_description": "Workloads run in TEE VMs; data encrypted via TLS 1.3.", "transparency_level": 4, "artifacts": [ "https://github.com/example/network/releases/tag/v1.0", "https://example-transparency-log.org/entries/12345" ] }, { "threat_identifier": "urn:ada:threat:tampering:code-change", "mitigation_description": "Workload runs in a hardware TEE w/ Remote Attestation.", "transparency_level": 2, "artifacts": [ "https://example.com/binaries/inference-node-v1.0.bin" ] } ] } ] } Laurie, et al. Expires 5 December 2026 [Page 8] Internet-Draft TMIF June 2026 NOTE: This is currently specified in JSON format for the purposes of providing an example, but the preferred format will depend on emerging use cases and we invite further discussion on this particular point. Individual values will be defined elsewhere in a decentralized way (e.g. on separate websites / GitHub readmes, etc.). 4.1.1. TMIF Field Definitions The fields used in the Transparency Metadata Interchange Format are defined below: system_identifier (String) A unique URN or identifier for the overall system being assessed. system_version (String) The version string of the overall system. valid_until A timestamp indicating when the TMIF document ceases to be valid, expressed as an Internet date-time string in full-date "T" full-time format conforming to [RFC3339]. transparency_level_lower_bound (Integer) The lowest (weakest) transparency level found across all mitigations in all components of the system. This reflects the aggregate health of the system. components (Array) A list of the distinct architectural components that make up the system (e.g., stateless inference service, stateful memory store). component_identifier (String) A unique URN identifying the specific component. component_version (String) The version of the component. claims (Array) A list of mitigation claims associated with this component. threat_identifier (String) A standardized URN representing the specific threat being mitigated (e.g., referencing a canonical threat library maintained by an evaluator like the App Defense Alliance). mitigation_description (String) A plain-text description of how the threat is mitigated (the technical solution). transparency_level (Integer) The transparency level (1-5) representing the available proof for this mitigation. Laurie, et al. Expires 5 December 2026 [Page 9] Internet-Draft TMIF June 2026 artifacts (Array of Strings) A simple list of URIs pointing to the verifiable evidence for the transparency level (e.g., links to open-source repositories, transparency logs, binary downloads, or audit reports). 4.2. Usage of Transparency Metadata The separation of concerns in TMIF allows it to be highly flexible: 1. *The Claimant (System Provider):* Identifies the threats relevant to their system (using evaluator-provided URNs), describes their mitigations, self-assesses their transparency level, and links to the artifact proofs in the TMIF document. 2. *The Evaluator (Auditing Body):* Parses the TMIF document, verifies the URIs in the artifacts array, and confirms the transparency_level. The evaluator then applies their own independent scoring methodology (e.g., mapping STRIDE threats to weights, multiplying weights by the TMIF transparency level) to arrive at an approval decision. IETF explicitly does not standardize the weights or the threat URNs, leaving that to the domain expertise of the evaluators. 5. Security Considerations TMIF documents communicate security and privacy claims but do not themselves enforce them. The integrity and authenticity of a TMIF document are paramount; if an attacker can maliciously alter a TMIF payload in transit, an evaluator could be misled into trusting a compromised or subverted component. 5.1. Claim Tampering and Integrity Protection To mitigate the risk of claim tampering, any system claiming compliance with this specification MUST ensure that TMIF payloads are cryptographically protected at the data layer. * *Data Structure Protection:* TMIF payloads MUST be encapsulated in a format that supports cryptographic signatures and data integrity proofs. Implementations MUST use JSON Web Signatures (JWS) [RFC7515]. * *Signature Verification:* The Relying Party or Verifier MUST cryptographically validate the signature of the TMIF record against a known, trusted Root of Trust before parsing or appraising the metadata. Payloads with invalid, missing, or malformed cryptographic signatures MUST be rejected immediately. Laurie, et al. Expires 5 December 2026 [Page 10] Internet-Draft TMIF June 2026 * *Transport Security:* While payload-level signing is required, TMIF transport channels SHOULD additionally utilize Transport Layer Security (TLS) [RFC8446] to ensure confidentiality and prevent traffic analysis. 5.2. Replay Attack Mitigations To prevent replay attacks where an historic, validly signed TMIF payload is substituted to mask a current compromised state, TMIF documents MUST include a cryptographically bound freshness mechanism. * Implementations MUST include a 'valid_until' timestamp parameter. * Verifiers MUST reject TMIF payloads if the current system time is past the designated expiration window. 6. IANA Considerations This document has no IANA actions. 7. References 7.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, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 7.2. Informative References Laurie, et al. Expires 5 December 2026 [Page 11] Internet-Draft TMIF June 2026 [I-D.ietf-rats-ar4si] Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si- 10, 18 May 2026, . [NIST-TCB] National Institute of Standards and Technology (NIST), "Glossary: Trusted Computing Base (TCB)", 2026, . [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, . Acknowledgments Authors' Addresses Ben Laurie Google LLC Email: benl@google.com Tiziano Santoro Google LLC Email: tzn@google.com Pauline Anthonysamy Google LLC Email: anthonysp@google.com Sarah de Haas Google LLC Email: dehaass@google.com Ankur Mathur Google LLC Email: ankurmathur@google.com Laurie, et al. Expires 5 December 2026 [Page 12]