A Standard for Claiming Transparency and Falsifiability
draft-laurie-tmif-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ben Laurie , Tiziano Santoro , Pauline Anthonysamy , Sarah de Haas , Ankur Mathur | ||
| Last updated | 2026-09-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-laurie-tmif-02
Network Working Group B. Laurie
Internet-Draft T. Santoro
Intended status: Informational P. Anthonysamy
Expires: 20 March 2027 S. de Haas
A. Mathur
Google LLC
16 September 2026
A Standard for Claiming Transparency and Falsifiability
draft-laurie-tmif-02
Abstract
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.
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/.
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/.
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/.
Laurie, et al. Expires 20 March 2027 [Page 1]
Internet-Draft TMIF September 2026
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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
2.1. System Component Definitions . . . . . . . . . . . . . . 4
3. Falsifiability of Privacy Claims . . . . . . . . . . . . . . 7
3.1. Transparency Levels . . . . . . . . . . . . . . . . . . . 8
4. Transparency Metadata Interchange Format (TMIF) . . . . . . . 8
4.1. Example TMIF Document . . . . . . . . . . . . . . . . . . 9
4.1.1. TMIF Field Definitions . . . . . . . . . . . . . . . 11
4.2. Usage of Transparency Metadata . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Claim Tampering and Integrity Protection . . . . . . . . 13
5.1.1. Claim Tampering and Integrity Protection . . . . . . 13
5.1.2. End-to-End Confidentiality & Access Control . . . . . 13
5.2. Replay Attack Mitigations . . . . . . . . . . . . . . . . 13
5.3. Realistic TEE Threat Model and Physical Attack
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Laurie, et al. Expires 20 March 2027 [Page 2]
Internet-Draft TMIF September 2026
1. Introduction
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.
Laurie, et al. Expires 20 March 2027 [Page 3]
Internet-Draft TMIF September 2026
+-------------------+ +--------------------+
| System Provider |----(TMIF)-->| Third-Party |
| (Claims Engine) | | Evaluator |
+-------------------+ +--------------------+
| |
(Attestation Evidence) (Verifies Proofs)
v v
+-------------------+ +--------------------+
| Hardware TEE | | Root of Trust |
+-------------------+ +--------------------+
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.
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.
Laurie, et al. Expires 20 March 2027 [Page 4]
Internet-Draft TMIF September 2026
Claimant 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.
Client The device (e.g., a smartphone, laptop, or web browser) used
to interact with the service. Includes software and hardware.
Evaluator 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.
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 A physical or virtualized compute node executing services
Laurie, et al. Expires 20 March 2027 [Page 5]
Internet-Draft TMIF September 2026
within the system.
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.
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.
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
Laurie, et al. Expires 20 March 2027 [Page 6]
Internet-Draft TMIF September 2026
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
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.
Laurie, et al. Expires 20 March 2027 [Page 7]
Internet-Draft TMIF September 2026
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 | Public | Binary digest is published in an |
| | Binary & Log | immutable, witnessable public |
| | | transparency log. |
+-------+--------------+--------------------------------------------+
| 2 | Publicly | Level 1 evidence + binary is executable |
| | Executable | in an accessible testbed/sandbox for |
| | | dynamic analysis & fuzzing. |
+-------+--------------+--------------------------------------------+
| 3 | Public | Complete source code matching the |
| | Source Code | released binary version is publicly |
| | | available. |
+-------+--------------+--------------------------------------------+
| 4 | Reproducible | Level 3 evidence + deterministic build |
| | Build | pipeline with signed build provenance |
| | | (SLSA Level 3+). |
+-------+--------------+--------------------------------------------+
| 5 | Formal | Machine-checked formal mathematical |
| | Verification | proof of cryptographic protocol |
| | | specifications and/or software |
| | | implementation invariants. |
+-------+--------------+--------------------------------------------+
Table 1: Standardized Transparency Levels
4. Transparency Metadata Interchange Format (TMIF)
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).
Laurie, et al. Expires 20 March 2027 [Page 8]
Internet-Draft TMIF September 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 20 March 2027 [Page 9]
Internet-Draft TMIF September 2026
; 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 ---
Laurie, et al. Expires 20 March 2027 [Page 10]
Internet-Draft TMIF September 2026
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
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
Laurie, et al. Expires 20 March 2027 [Page 11]
Internet-Draft TMIF September 2026
how the threat is mitigated (the technical solution).
transparency_level (Integer) The transparency level (1-5)
representing the available proof for this mitigation.
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 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.
2. *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.
3. *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).
4. *The Relying Party:* Consumes Attestation Results to make risk-
informed authorization decisions before releasing sensitive user
data.
5. Security Considerations
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.
Laurie, et al. Expires 20 March 2027 [Page 12]
Internet-Draft TMIF September 2026
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.
5.1.1. Claim Tampering and Integrity Protection
* *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.
5.1.2. End-to-End Confidentiality & Access Control
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.
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.
* 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.
Laurie, et al. Expires 20 March 2027 [Page 13]
Internet-Draft TMIF September 2026
5.3. Realistic TEE Threat Model and Physical Attack Boundaries
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.
6. IANA Considerations
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.
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[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/rfc/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/rfc/rfc7516>.
Laurie, et al. Expires 20 March 2027 [Page 14]
Internet-Draft TMIF September 2026
[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/rfc/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[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/rfc/rfc9052>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
7.2. Informative References
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-10>.
[NIST-TCB] National Institute of Standards and Technology (NIST),
"Glossary: Trusted Computing Base (TCB)", 2026,
<https://csrc.nist.gov/glossary/term/
trusted_computing_base>.
[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/rfc/rfc9334>.
[RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig,
"Remote ATtestation procedureS (RATS) Conceptual Message
Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026,
<https://www.rfc-editor.org/rfc/rfc9999>.
Acknowledgments
Authors' Addresses
Laurie, et al. Expires 20 March 2027 [Page 15]
Internet-Draft TMIF September 2026
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 20 March 2027 [Page 16]