| Internet-Draft | TMIF | September 2026 |
| Laurie, et al. | Expires 20 March 2027 | [Page] |
This document specifies a Transparency Metadata Interchange Format (TMIF) that allows a distributed or confidential computing system to make standardized, verifiable claims about its levels of transparency and falsifiability. Modeled as a structured Endorsement within the Remote Attestation Procedures (RATS) architecture, TMIF provides an agnostic, schema-defined communication vehicle for claimants to declare how their security mitigations and policy governance controls can be independently inspected, reproduced, and verified by third-party evaluators.¶
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/.¶
Discussion of this document takes place on the Remote ATtestation ProcedureS (RATS) Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/.¶
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 20 March 2027.¶
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.¶
As AI-powered services and distributed confidential computing environments proliferate, sensitive workloads increasingly process private user data in remote cloud or edge infrastructure. This introduces critical trust challenges: users, enterprise relying parties, regulators, and security researchers require cryptographic assurances that data is handled strictly in accordance with published privacy invariants and security mitigations. While hardware Trusted Execution Environments (TEEs) provide execution isolation and remote attestation, attestation alone does not communicate the degree to which the underlying software components, build pipelines, and governance policies are independently inspectable, reproducible, and falsifiable.¶
This document defines the Transparency Metadata Interchange Format (TMIF). Operating as a standardized Endorsement format within the Remote Attestation Procedures (RATS) architecture [RFC9334], TMIF provides an extensible, schema-defined mechanism for claimants to declare the transparency levels of their system components, the specific threats or governance requirements mitigated, and the verifiable artifacts supporting those claims.¶
Crucially, TMIF separates the communication of transparency metadata from the evaluation and scoring of threat models. It does not prescribe specific threat frameworks (e.g., STRIDE, ISO/IEC, or App Defense Alliance taxonomies) or proprietary scoring weights. Instead, it defines a standard structure (specified in CDDL [RFC8610] for both JSON and CBOR representations) allowing claimants to catalog mitigated threats and governance policies via standard URNs, describe mitigations, and declare the transparency level (the technical evidence) of each mitigation. Independent evaluators, auditors, and verifiers can then ingest TMIF documents as inputs to appraisal policies or certification workflows.¶
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 runtime attestation frameworks such as Attestation Results for Secure Interactions [I-D.ietf-rats-ar4si] and EAT Attestation Results (EAR) communicate the dynamic operational state of an Attester, TMIF communicates the design-time transparency, build reproducibility, and public auditability of the system.¶
+-------------------+ +--------------------+
| System Provider |----(TMIF)-->| Third-Party |
| (Claims Engine) | | Evaluator |
+-------------------+ +--------------------+
| |
(Attestation Evidence) (Verifies Proofs)
v v
+-------------------+ +--------------------+
| Hardware TEE | | Root of Trust |
+-------------------+ +--------------------+
¶
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.¶
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:¶
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.¶
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.¶
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.¶
The entity (such as a device OEM or service provider) generating the TMIF document to assert the transparency of their system. In RATS terminology [RFC9334], the Claimant acts as an Endorser asserting design-time mitigation claims, transparency levels, and verifiable proof artifacts.¶
The device (e.g., a smartphone, laptop, or web browser) used to interact with the service. Includes software and hardware.¶
An independent third party, auditor, or certification body (such as the App Defense Alliance or independent security research lab) that ingests the TMIF Endorsement, validates the declared artifacts (open-source repositories, reproducible build attestations, public transparency log proofs, or formal verification models), and applies appraisal policies to evaluate compliance or generate reference appraisal results for Verifiers and Relying Parties.¶
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.¶
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.¶
TEE environments provide memory protection, even from software with higher privilege.¶
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.¶
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).¶
A physical or virtualized compute node executing services within the system.¶
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.¶
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.¶
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.¶
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.¶
TEEs operate under defined physical and software threat boundaries. While server-class TEEs provide strong isolation against privileged host software and hypervisors, resilience against physical attacks (e.g., bus tapping, fault injection, memory bus interposition) depends on specific hardware designs. Claimants MUST document physical security scope in their threat claims.¶
The hardware vendor that designs and manufactures the processor containing the TEE.¶
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.¶
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.¶
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.¶
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 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.¶
Falsifiability is fundamentally anchored in public, tamper-evident transparency logs and multi-party witness networks. By logging cryptographic digests of binaries, build provenance, and configuration manifests to immutable append-only ledgers co-signed by independent third-party witnesses (e.g., Cloudflare, Glasklar Teknik, Geomys), claimants ensure retroactive falsifiability: any unauthorized binary or subverted build deployed to production leaves an indelible public record that external researchers can independently discover and audit.¶
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 | Public Binary & Log | Binary digest is published in an immutable, witnessable public transparency log. |
| 2 | Publicly Executable | Level 1 evidence + binary is executable in an accessible testbed/sandbox for dynamic analysis & fuzzing. |
| 3 | Public Source Code | Complete source code matching the released binary version is publicly available. |
| 4 | Reproducible Build | Level 3 evidence + deterministic build pipeline with signed build provenance (SLSA Level 3+). |
| 5 | Formal Verification | Machine-checked formal mathematical proof of cryptographic protocol specifications and/or software implementation invariants. |
The Transparency Metadata Interchange Format is an extensible schema designed to communicate a system's composition, the claims it makes against standardized threats and policy governance requirements, the mitigations implemented, and the transparency level of those mitigations. It is specified in Concise Data Definition Language (CDDL) [RFC8610] and supports both JSON and CBOR encodings.¶
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).¶
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.¶
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"
]
}
]
}
]
}
¶
; CDDL Specification (RFC 8610) for TMIF
tmif-document = {
"system_identifier": uri-or-urn,
"system_version": tstr,
? "issued_at": time-rfc3339,
"valid_until": time-rfc3339,
? "nonce": bstr / tstr,
"transparency_level_lower_bound": transparency-level,
"components": [+ component-entry],
? "governance_claims": [+ governance-claim-entry],
? "extensions": { * tstr => any },
* $$tmif-extension
}
component-entry = {
"component_identifier": uri-or-urn,
"component_version": tstr,
? "submodules": [+ component-entry],
"claims": [+ mitigation-claim],
* $$component-extension
}
mitigation-claim = {
"threat_identifier": uri-or-urn,
? "threat_category": threat-category,
"mitigation_description": tstr,
"transparency_level": transparency-level,
? "formal_proof_scope": proof-scope,
"artifacts": [+ uri-or-urn],
* $$claim-extension
}
governance-claim-entry = {
"policy_identifier": uri-or-urn,
"authority_tier": tstr,
"jurisdiction": tstr,
"enforcement_mechanisms": [+ tstr],
"transparency_level": transparency-level,
"artifacts": [+ uri-or-urn]
}
; --- Types and Enums ---
transparency-level = 1..5
threat-category = "stride" / "policy_governance" / "physical" / tstr
proof-scope = "protocol" / "implementation" / "both" / tstr
uri-or-urn = tstr ; Alternatively: uri / tstr
time-rfc3339 = tstr ; Matches date-time format per RFC 3339
¶
The fields used in the Transparency Metadata Interchange Format are defined below:¶
A unique URN or identifier for the overall system being assessed.¶
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].¶
The lowest (weakest) transparency level found across all mitigations in all components of the system. This reflects the aggregate health of the system.¶
A list of the distinct architectural components that make up the system (e.g., stateless inference service, stateful memory store).¶
A unique URN identifying the specific component.¶
The version of the component.¶
A list of mitigation claims associated with this component.¶
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).¶
A plain-text description of how the threat is mitigated (the technical solution).¶
The transparency level (1-5) representing the available proof for this mitigation.¶
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).¶
The separation of concerns in TMIF allows it to be highly flexible:¶
The Claimant (System Provider): Identifies the threats and governance rules relevant to their system (using standardized URNs), describes technical mitigations, self-assesses transparency levels, and links to verifiable artifact proofs in the signed TMIF Endorsement.¶
The Evaluator (Auditing Body): Parses the TMIF document, cryptographically verifies the artifact URIs against public transparency logs and source repositories, and validates declared transparency levels. Evaluators apply their domain scoring models (e.g., App Defense Alliance or CCC profiles) to issue appraisal statements or certification endorsements.¶
The Verifier: Ingests TMIF Endorsements alongside runtime Attestation Evidence from the Attester. Verifies cryptographic signatures, freshness nonces, and transparency bounds against appraisal policies to produce trusted Attestation Results (EAR/AR4SI).¶
The Relying Party: Consumes Attestation Results to make risk-informed authorization decisions before releasing sensitive user data.¶
TMIF documents communicate security, privacy, and governance claims but do not themselves enforce runtime isolation. The integrity, authenticity, confidentiality, and freshness of a TMIF document are paramount; if an attacker can alter, relay, or forge TMIF metadata, relying parties and evaluators could be misled into trusting compromised or subverted components.¶
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 supporting cryptographic signatures and data integrity proofs. Implementations MUST use JSON Web Signatures (JWS) [RFC7515] or COSE-Sign [RFC9052].¶
Signature Verification: The Verifier or Evaluator MUST cryptographically validate the signature of the TMIF record against a trusted Root of Trust before parsing or appraising metadata. Payloads with invalid, missing, or untrusted signatures MUST be rejected immediately.¶
Where TMIF documents contain proprietary system topologies, unpublished vulnerability mitigations, or sensitive enterprise governance configurations, payloads MAY be encrypted end-to-end using JSON Web Encryption (JWE) [RFC7516] or COSE-Encrypt. Transport channels SHOULD enforce mutual TLS (mTLS) with client authentication [RFC9846] to restrict access to authorized evaluators.¶
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.¶
Temporal Freshness: TMIF documents MUST include a 'valid_until' timestamp parameter conforming to RFC 3339. Verifiers MUST reject TMIF payloads if current system time exceeds expiration or precedes 'issued_at'.¶
Interactive Nonces: In challenge-response or interactive attestation sessions, TMIF queries SHOULD include a cryptographic 'nonce' provided by the verifier to ensure strict replay protection within the validity window.¶
Hardware TEEs operate under defined physical and hardware boundaries: * Physical Attack Scope: Standard cloud server TEEs (e.g., AMD SEV-SNP, Intel TDX) primarily defend against privileged host software and hypervisors; they may not inherently mitigate physical bus interposition, memory bus tapping, fault injection, or side-channel attacks (e.g., TEE.fail, wiretap.fail, BadRAM). Claimants MUST explicitly declare whether physical threats are in-scope and document physical mitigation evidence. * Diversion and Relay Attacks: Attackers may attempt to divert authentic attestation evidence or TMIF metadata across sessions. Systems MUST cryptographically bind TMIF endorsements and attestation quotes to the communication channel (e.g., using TLS exporter channel binding, token binding, or embedding transport public keys into attestation nonces). * Conveyance Protocols: Implementations MAY use the Secure Transiting of Evidence and Endorsements in TEEs (STET) protocol [RFC9999] or HTTPS REST profiles to convey TMIF payloads securely.¶
This document requests IANA to register the media types application/tmif+json and application/tmif+cbor, and establish the URN namespace urn:ietf:params:tmif: for standardized threat and governance identifiers.¶