Privacy Framework for Remote ATtestation procedureS
draft-ounsworth-rats-privacy-framework-00
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 | Mike Ounsworth , Hannes Tschofenig , Guiliano Lehmann | ||
| Last updated | 2026-06-18 | ||
| 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-ounsworth-rats-privacy-framework-00
RATS M. Ounsworth
Internet-Draft Cryptic Forest Software
Intended status: Informational H. Tschofenig
Expires: 20 December 2026 UniBw M.
G. Lehmann
H-BRS
18 June 2026
Privacy Framework for Remote ATtestation procedureS
draft-ounsworth-rats-privacy-framework-00
Abstract
This document extends the RATS Architecture to consider "coercive
uses of RATS" where a malicious Verifier or Relying Party uses RATS
protocols to extract sensitive information from an Attester or a
victim Verifier that it would not otherwise be inclined to disclose.
This over-disclosure can include revealing sensitive measurements,
stable identifiers, device fingerprints, vendor information, or
conclusions derived from Evidence. This document defines a privacy
framework for Remote Attestation that identifies this threat
surfaces; classifies claims produced by Attesters and Presenters;
restricts sensitive Evidence disclosure to authorized Trusted
Verifiers using confidentiality protection; and describes privacy-
preserving Attestation Results based on data minimization, Selective
Disclosure, and Zero-Knowledge Proofs.
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 20 December 2026.
Ounsworth, et al. Expires 20 December 2026 [Page 1]
Internet-Draft RATS Privacy Framework 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Threat Surfaces . . . . . . . . . . . . . . . . . . . . . 4
1.3. The Framework . . . . . . . . . . . . . . . . . . . . . . 5
1.4. RFC 6973 Identity Roles in RATS . . . . . . . . . . . . . 5
1.5. RATS Topologies and Privacy . . . . . . . . . . . . . . . 6
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
3. Classification of Claims . . . . . . . . . . . . . . . . . . 7
3.1. Identity-Related Information . . . . . . . . . . . . . . 7
3.2. Attester Identifiers . . . . . . . . . . . . . . . . . . 8
3.3. Fingerprints . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Vendor Info . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Unclassified . . . . . . . . . . . . . . . . . . . . . . 9
4. Technical Framework . . . . . . . . . . . . . . . . . . . . . 9
4.1. Trusted Verifiers . . . . . . . . . . . . . . . . . . . . 10
4.2. Evidence Encryption . . . . . . . . . . . . . . . . . . . 10
4.3. Attestation Result Minimization . . . . . . . . . . . . . 12
4.4. Selective Disclosure in Attestation Results . . . . . . . 12
4.5. Zero-Knowledge Proofs in Attestation Results . . . . . . 13
4.6. Relationship to Privacy Pass . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Ounsworth, et al. Expires 20 December 2026 [Page 2]
Internet-Draft RATS Privacy Framework June 2026
1. Introduction
1.1. Problem Statement
In its conception, remote attestation focuses on measured boot where
Evidence typically consists of measurements of hardware, firmware,
and software components. This data is often treated as operational
security data rather than privacy-sensitive data. The RATS
Architecture [RFC9334] assumes that the purpose of remote attestation
is for the Attester to prove its own trustworthiness to a Verifier or
Relying Party, but it considers only in passing that the Verifier or
Relying Party could be malicious and coercively using Remote
Attestation to extract sensitive data from an Attester. This
document challenges that assumption and fills in the gaps by
providing a framework that can be applied consistently across RATS
under which sensitive claims and sensitive conclusions derived from
those claims can be safely handled by all RATS entities. While the
RATS Architecture [RFC9334] mentions in passing the need for a
Verifier to be authenticated, and the Entity Attestation Token (EAT)
[RFC9711] includes a mechanism for encrypting Evidence, this document
provides a framework for doing this in a consistent manner.
This document uses the privacy terminology from [RFC6973] rather than
relying on jurisdiction-specific legal terms. RFC 6973 defines an
Identity as any subset of an individual's attributes, including
names, that identifies the individual within a given context. It
defines an Identifier as a data object uniquely referring to an
entity in some context. It also defines a Fingerprint as a set of
information elements that identifies a device or application
instance.
Remote attestation usually discloses software and hardware attributes
of an Attesting Environment rather than attributes of a human
individual. Examples include firmware versions, software manifests,
configuration measurements, attestation public keys, device serial
numbers, and hardware capabilities. When an Attester is associated
with an individual, household, or organization, those attributes can
enable identification, correlation, secondary use, or disclosure
concerning that associated party.
This document also defines Vendor Info as a sensitive category of
remote attestation Evidence. The 2023 IAB Statement on the Risks of
Attestation of Software and Hardware on the Open Internet
[IAB-Statement-2023] does not use this term, but discusses the
related risk that attestation mechanisms can be used to restrict
access to otherwise open services based on client software or
hardware properties.
Ounsworth, et al. Expires 20 December 2026 [Page 3]
Internet-Draft RATS Privacy Framework June 2026
Overly-verbose Attestation Results can further propagate the privacy
risks even when the original Evidence is never disclosed to the
Relying Party. The privacy problem is therefore multi-faceted:
sensitive Evidence needs to be protected from passive eavesdroppers
in transit to the Verifier, the Verifier needs to be authenticated
and authorized to view sensitive Evidence, and Attestation Results
disclosed to Relying Parties needs to minimize the inclusion of
sensitive claims.
In addition to claims being privacy sensitive, they can also be
sensitive in a security sense; being able to view the complete
configuration state of a device can greatly aid an attacker in
compromising that device for example the manifest of firmware and
software versions tells an attacker which known vulnerabilities to
try, and the configuration state of the device (such as an increase
in the boot counter) could give the attacker confirmation that the
attack was successful.
1.2. Threat Surfaces
This document distinguishes three privacy threat surfaces.
* *Disclosure to the Verifier.* The Verifier appraises Evidence and
therefore often needs detailed claims, Endorsements, Reference
Values, and appraisal policy. A framework can reduce unnecessary
disclosure to Verifiers by using claim classification, trust
anchor stores for Trusted Verifiers, purpose-specific policies,
and encrypted Evidence, but it cannot eliminate the need for the
Verifier to receive enough information to perform appraisal. In
this sense, disclosure to the Verifier is a privacy risk that can
be constrained, audited, and made explicit, but not generally
removed.
* *Disclosure to the Relying Party.* The Relying Party applies an
Appraisal Policy for Attestation Results to decide whether to rely
on the Attester. In many deployments, this decision can be made
from a minimized Attestation Result, from selectively disclosed
claims, or from a proof of a policy predicate. This is the
primary privacy focus of this framework. Relying Parties
generally do not need raw Evidence or detailed Attestation Results
unless those details are necessary for their own policy decision
and are authorized by the Attester or device owner.
* *Disclosure to eavesdroppers.* Evidence, Attestation Results, and
related artifacts can be observed on communication interfaces
between Attester, Presenter, Relying Party, and Verifier.
Communication security protection, as provided by TLS, is
necessary for these interfaces. Object security, such as
Ounsworth, et al. Expires 20 December 2026 [Page 4]
Internet-Draft RATS Privacy Framework June 2026
encrypting Evidence for the Verifier, provides additional
protection against incidental logging, misrouting, intermediaries,
and Relying Parties that carry Evidence but are not authorized to
inspect it.
This threat separation is important because different controls apply
to each case. Encrypting Evidence for a Verifier protects against
eavesdroppers and against Relying Parties that forward Evidence in
the Background-Check Model, but it does not minimize what the
Verifier learns. TLS protects communication channels, but it does
not prevent an authorized recipient from learning or retaining
excessive claims. Selective Disclosure and Zero-Knowledge Proofs can
minimize what a Relying Party learns from an Attestation Result, but
they do not replace the Verifier's appraisal of Evidence.
1.3. The Framework
This document provides a remote attestation privacy framework in four
parts.
First is a conceptual framework for classifying Evidence claims and
Attestation Result claims as identity-related information, Attester
Identifiers, Fingerprints, Vendor Info, or unclassified.
Second is a threat framework that separates disclosure to Verifiers,
disclosure to Relying Parties, and disclosure to eavesdroppers.
Third is a technical framework whereby an attesting client (RATS
Attester or Presenter) maintains one or more trust anchor stores for
Trusted Verifiers and encrypts sensitive Evidence for authorized
Verifiers.
Fourth is a technical framework for minimizing Attestation Results
before they are disclosed to Relying Parties. This includes
conventional data minimization, Selective Disclosure, and Zero-
Knowledge Proofs.
1.4. RFC 6973 Identity Roles in RATS
RFC 6973 defines a Relying Party as an entity that relies on
assertions of identities from Identity Providers in order to provide
services. The RATS Relying Party role is similar in that it relies
on assertions produced by another party, namely Attestation Results
produced by a RATS Verifier.
The RATS Verifier can act as an Identity Provider vouching for the
identity of the Attester in the limited sense that it can include
identifier claims in Attestation Results, but RATS Verifier goes
Ounsworth, et al. Expires 20 December 2026 [Page 5]
Internet-Draft RATS Privacy Framework June 2026
beyond the scope of [RFC6973] establishing, maintaining, securing,
and vouching for claims about the entire posture of Attester beyond
merely its identity. Therefore,, this analogy is not intended to be
read too broadly. A RATS Verifier typically vouches for attributes
of a device, workload, execution environment, or composite Attester,
not for the identity of a human individual. The Attestation Result
might contain a device Identifier, a pseudonymous Attester
Identifier, a set of attributes, a policy decision, or a proof about
such attributes. Only in deployments where the Attester is bound to
an individual, or where Evidence carries user authentication
material, does the Verifier's output become an assertion about a
human identity.
This distinction is important for privacy analysis. RATS can create
identity-management-like flows even when the subject of the assertion
is not a person. The privacy risks arise because device and workload
attributes can still identify, fingerprint, or correlate the
Attester, and because the Attester can be associated with an
individual, organization, or role.
1.5. RATS Topologies and Privacy
The RATS architecture defines the Passport Model and the Background-
Check Model [RFC9334]. These topologies have different privacy
properties and therefore require separate analysis.
In the *Passport Model*, the Attester obtains an Attestation Result
from a Verifier and presents it to a Relying Party. The Relying
Party does not need to carry raw Evidence to the Verifier. This
topology is generally preferable when the privacy goal is to keep raw
Evidence away from Relying Parties. If the Attester-to-Verifier and
Attester-to-Relying-Party channels are protected with TLS or
equivalent channel security, encrypting Evidence as an object
provides less incremental protection against network eavesdroppers
than it does in the Background-Check Model. However, object
encryption can still be useful for protecting Evidence from
intermediaries, logging systems, queueing infrastructure, or
Presenters that are not authorized to inspect the Evidence, which is
especially relevant in cloud environments where TLS is terminated at
the network edge. In the Passport Model, the main privacy challenge
usually moves from Evidence confidentiality to Attestation Result
minimization.
In the *Background-Check Model*, the Relying Party obtains Evidence
from the Attester and sends it to the Verifier. This topology
creates a stronger privacy risk because the Relying Party is on the
Evidence path. If the Evidence is only protected by TLS on each hop,
the Relying Party can observe, log, retain, or correlate the
Ounsworth, et al. Expires 20 December 2026 [Page 6]
Internet-Draft RATS Privacy Framework June 2026
Evidence. Encrypting the Evidence for the Verifier changes this
property: the Relying Party can carry the Evidence to the Verifier
without learning its sensitive contents, or being legally responsible
for the correct handling of this content. Therefore, encrypted
Evidence provides a direct privacy benefit in the Background-Check
Model. Nevertheless, the Background-Check Model still requires
careful minimization of the Attestation Result returned to the
Relying Party. If the result reveals the same sensitive details that
were hidden in the encrypted Evidence, the privacy gain is lost.
Combinations of the two models inherit the risks of each path.
Implementations need to analyze which roles can observe Evidence,
which roles can observe Attestation Results, and which parties can
correlate presentations over time.
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. Classification of Claims
For the purposes of this document, an attestation client is either an
Attester directly, or a Presenter acting as a proxy between the
Attester and the Verifier. A conforming client is responsible for
classifying every Evidence claim that it is capable of producing
according to the following categories. Verifiers producing
Attestation Results SHOULD also be aware of the classification of
claims in a given Evidence format, and have appropriate policy for
transforming sensitive claims into Attestation Results. For example,
if a firmware version claim would be Vendor Info in Evidence, then an
Attestation Result claim that reveals the same firmware version is
also Vendor Info.
3.1. Identity-Related Information
Identity-related information is any Evidence or Attestation Result
claim that contains or can reveal an Identity, Identifier, or
Attribute of an individual as those terms are used in [RFC6973].
Examples include account names, user names, email addresses,
biometric authentication attributes, or identity claims carried by
embedded authentication formats.
Ounsworth, et al. Expires 20 December 2026 [Page 7]
Internet-Draft RATS Privacy Framework June 2026
Many RATS deployments will not disclose human identities directly.
However, a device, workload, or execution environment can be closely
associated with an individual or a small group. In such deployments,
Attester Identifiers and Fingerprints can become identity-related
information because they allow a Relying Party or other observer to
link protocol interactions to the associated individual or group.
3.2. Attester Identifiers
An Attester Identifier is any data object that uniquely refers to a
specific Attester, device, workload, or execution environment in some
context. This category applies the RFC 6973 concept of an Identifier
to RATS protocol entities and subjects. Attester Identifiers include
the obvious things such as serial numbers of either the device or of
certificates issued to the device, cryptographic public keys,
persistent pseudonyms, static addresses, and stable key identifiers.
Sometimes Attester Identifiers are hiding in places that even the
implementers might not be aware of, such as DNs, certificate serial
numbers, public keys of certificates issued to the hardware at
manufacture-time, or stable values in Endorsements. Implementers
need to be especially aware of multiple claims being used in
aggregate to form a stable fingerprint that can be used as a stand-in
for an identifier, as described in the next section. Attester
Identifiers are privacy-sensitive because they enable correlation
across protocol interactions, Relying Parties, or administrative
domains.
3.3. Fingerprints
A Fingerprint is a set of information elements that identifies a
device or application instance, as described in [RFC6973]. In RATS,
this includes hardware manifests such as the model numbers of all
connected peripheral devices, manifests of installed software,
detailed configuration measurements, or combinations of appraisal
outcomes that are sufficiently distinctive. Implementations SHOULD
also consider hashes of firmware, software, or filesystem contents,
especially where this is user-customizable, because these values can
quickly become unique Fingerprints.
Fingerprints differ from explicit Attester Identifiers because no
single claim is necessarily unique. The combination of claims can
nevertheless identify the Attester with high probability. This makes
Fingerprints especially easy to overlook when designing Evidence and
Attestation Result formats.
Ounsworth, et al. Expires 20 December 2026 [Page 8]
Internet-Draft RATS Privacy Framework June 2026
3.4. Vendor Info
Vendor Info is any Evidence claim that can be used, in isolation or
in aggregate, to identify the model and manufacturer of a device.
Obvious examples include version information about hardware,
firmware, and software, or manufacturer-issued certificates.
Implementers SHOULD also consider fingerprints that are unique to a
given device model or manufacturer, which could include hashes of
firmware or software.
The main privacy concern is that Vendor Info can enable policy
decisions based on implementation provenance rather than protocol
compliance, including proprietary vendor lock-in, forced
obsolescence, or other exclusion of otherwise compliant and
interoperable implementations. Such policies can be appropriate
within an explicit administrative trust boundary, such as an
enterprise network, datacenter, or managed service environment. In
open Internet deployments, devices SHOULD NOT disclose Vendor Info
unless the device owner has explicitly consented to onboard the
device into a service or network that requires this visibility.
3.5. Unclassified
This document defines an unclassified claim as any claim that does
not meet the definition of any of the categories above, and thus MAY
be freely released from the device without any access control or
confidentiality protection.
This document does not preclude the development of further categories
of sensitive claims.
4. Technical Framework
The technical framework presented here requires conformant
implementations to apply privacy controls at two different
information disclosure points.
First, Attesters and Presenters control release of Evidence to
Verifiers. They maintain lists of Trusted Verifiers (either
directly, or via chaining to a store of trusted roots) and the
categories of sensitive claims that those Verifiers are authorized to
request. Verifiers requesting sensitive claims are required to
provide an encryption credential compatible with the object security
mechanism used by the deployment, such as COSE or JOSE HPKE, so that
Evidence can be encrypted for them.
Ounsworth, et al. Expires 20 December 2026 [Page 9]
Internet-Draft RATS Privacy Framework June 2026
Second, Verifiers control release of Attestation Results to Relying
Parties. They minimize the content of Attestation Results and MAY
use Attestation Result formats based on Selective Disclosure or Zero-
Knowledge Proof technologies when the Relying Party's policy can be
satisfied without revealing detailed claims.
4.1. Trusted Verifiers
Conformant Clients, which could be either an Attester directly, or a
Presenter acting as a proxy for the Attester, MUST have a mechanism
to maintain trust anchor stores representing Trusted Verifiers. The
trust anchors could be self-signed certificates, public keys such as
those described in [RFC7250], [RFC5280], and [RFC5914], or JWK keys
as per [RFC7517]. The details of maintaining a trust anchor store
and performing path validation against the trust anchor store are out
of scope of this document.
Conformant Clients SHOULD have a mechanism to restrict released
information based on the authorization level of the Verifier. A
simple all-or-nothing approach would be refuse to return any Evidence
except to authorized Verifiers who can access the entire content.
Or, an Attester might have a "public" version of the Evidence with
only minimal content. Or, an Attester might have a complex mechanism
to authorize a given Verifier for a given category of claims or even
for specific claims.
4.2. Evidence Encryption
Conformant Clients MUST NOT release Evidence containing sensitive
claims in plaintext. Instead, Verifiers MUST provide an encryption
credential chaining to a trust anchor in the relevant trust anchor
store that can be used to encrypt the attestation payload.
Where the Verifier's encryption credential is an X.509 certificate,
it MUST contain an encryption-type keyUsage of keyEncipherment,
dataEncipherment, or keyAgreement and MUST contain the Extended Key
Usage id-kp-tbd-evidence-encryption.
Ounsworth, et al. Expires 20 December 2026 [Page 10]
Internet-Draft RATS Privacy Framework June 2026
If the attestation payload contains at least one claim of a sensitive
category, then the sensitive payload MUST be confidentiality
protected for the Verifier. Evidence can be represented in many
different formats, including proprietary formats. For standardized
Entity Attestation Token (EAT) Evidence [RFC9711], the following
encoding-specific guidance applies. For CBOR/COSE-encoded Evidence,
deployments SHOULD use COSE encryption structures with COSE HPKE
[COSE-HPKE]. For JSON/JOSE-encoded Evidence, deployments SHOULD use
JOSE encryption structures with JOSE HPKE [JOSE-HPKE]. When the
Conceptual Message Wrapper (CMW) [CMW] is used, the choice of
encryption envelope SHOULD match the underlying Evidence encoding in
order to reduce parser burden.
This specification does not preclude the development of additional or
proprietary Evidence formats which are free to specify their own
object encryption mechanism, provided that it is compliant with the
privacy objectives laid out in this document.
Object encryption does not replace channel security. Attester-to-
Verifier, Attester-to-Relying-Party, Relying-Party-to-Verifier, and
Verifier-to-Relying-Party interfaces SHOULD use TLS or equivalent
channel protection. Object encryption provides protection that
channel security alone does not provide when Evidence traverses an
entity that is allowed to forward but not inspect it, or when
messages are logged, queued, retried, or processed by intermediaries.
Evidence encryption MUST be bound to the intended Verifier and to the
protocol context. Deployments SHOULD use protected headers,
additional authenticated data, or equivalent mechanisms to bind the
ciphertext to the recipient, Evidence type, nonce or freshness value,
and any Relying Party challenge that the Verifier is expected to
appraise. Unprotected metadata SHOULD be minimized and MUST NOT
contain sensitive claims. For CBOR Web Tokens (CWTs), RFC 9597
[RFC9597] defines a mechanism for carrying CWT Claims in COSE
headers. This mechanism can be useful in the Background-Check Model
when a Relying Party needs to relay encrypted Evidence to the correct
Verifier and the type information available in the CMW is not
sufficient for routing. Any CWT Claims placed in COSE headers for
this purpose MUST be limited to non-sensitive routing information.
If such claims are carried in unprotected COSE headers, recipients
MUST treat them as untrusted until the Verifier has completed
cryptographic validation.
Ounsworth, et al. Expires 20 December 2026 [Page 11]
Internet-Draft RATS Privacy Framework June 2026
4.3. Attestation Result Minimization
Verifiers MUST treat Attestation Results as potentially sensitive.
An Attestation Result can reveal sensitive claims directly, or it can
reveal sensitive information indirectly by exposing detailed
appraisal outcomes.
A Verifier producing an Attestation Result for a Relying Party SHOULD
disclose the least information needed for the Relying Party's
Appraisal Policy for Attestation Results. Where possible, Verifiers
SHOULD disclose a coarse-grained status, policy identifier, assurance
level, or authorization decision instead of raw Evidence-derived
values. For example, a Relying Party that only needs to know whether
the Attester satisfies an enterprise baseline SHOULD receive a result
such as "baseline satisfied" and relevant freshness information,
rather than a complete software bill of materials or a list of
component versions.
Attestation Results intended for different Relying Parties SHOULD be
audience-restricted and purpose-specific. A result created for one
Relying Party MUST NOT be usable as a bearer artifact at a different
Relying Party unless the privacy and security policy explicitly
permits that use. Attestation Results SHOULD avoid stable
identifiers unless the Relying Party is authorized to identify or
correlate the Attester. When an identifier is needed, deployments
SHOULD prefer pairwise, audience-specific, or short-lived identifiers
over globally stable identifiers.
The Verifier SHOULD maintain policy describing which Relying Parties
are authorized to receive which categories of Attestation Result
claims. The policy SHOULD be at least as strict as the policy used
by Attesters and Presenters when releasing sensitive Evidence to
Verifiers.
4.4. Selective Disclosure in Attestation Results
Selective Disclosure is useful when an Attestation Result contains
multiple claims, but a Relying Party is authorized to learn only a
subset of them and the Verifier does not want to, or due to the
network protocol is not capable of, producing per-Relying Party
Attestation Results. In this model, the Verifier acts as the issuer
of a privacy-preserving Attestation Result, the Attester or Presenter
acts as the holder that chooses which disclosable claims to present,
and the Relying Party acts as the verifier of that selectively
disclosed result. This role mapping is separate from the RATS role
named Verifier.
Ounsworth, et al. Expires 20 December 2026 [Page 12]
Internet-Draft RATS Privacy Framework June 2026
For CBOR and COSE deployments, Attestation Results that are
represented as CWTs SHOULD consider Selective Disclosure CWTs
[SD-CWT]. SD-CWT defines a data minimization technique for CWTs
aligned with COSE and CWT, including a holder presentation flow and
COSE header parameters for disclosed claims. An SD-CWT-based
Attestation Result can allow a holder to disclose only claims needed
by a given Relying Party, such as a policy identifier, freshness
value, or coarse-grained assurance level, while withholding other
claims.
For JSON and JOSE deployments, Attestation Results that are
represented as JWTs or verifiable credential-like tokens SHOULD
consider SD-JWT [SD-JWT]. An SD-JWT-based Attestation Result can
support existing JOSE-based Relying Party ecosystems while enabling
disclosure of only selected claims.
Selective Disclosure is not sufficient by itself to prevent all
correlation. Undisclosed claims can still be inferred from disclosed
claim combinations, credential type identifiers, issuer identifiers,
timestamps, key-binding material, or unique metadata. Deployments
using Selective Disclosure for Attestation Results SHOULD minimize
metadata, use audience restriction, support nonce-based freshness,
and consider decoy digests or batch issuance where supported by the
selected format.
4.5. Zero-Knowledge Proofs in Attestation Results
Zero-Knowledge Proofs are useful when a Relying Party does not need a
claim value, but only needs assurance that a predicate over one or
more claims is true. Examples include proving that a firmware
version is at least a required version without revealing the exact
version, proving that a measured component is a member of an approved
set without revealing which member, or proving that an Attester has a
certified hardware capability without revealing the manufacturer or
model.
JOSE work on JSON Web Proof (JWP) [JWP], JSON Proof Token (JPT) and
CBOR Proof Token (CPT) [JPT], and JSON Proof Algorithms (JPA) [JPA]
is applicable to privacy-preserving Attestation Results. JWP defines
a proof-oriented container with a presentation form for selective
disclosure and proof computation. JPT and CPT define compact claim
token formats with selective disclosure, and support unlinkability
and reusability when used with ZKPs. JSON Proof Algorithms define
algorithm identifiers for use with JWP, JWK, and COSE.
An Attestation Result profile using ZKPs SHOULD specify:
Ounsworth, et al. Expires 20 December 2026 [Page 13]
Internet-Draft RATS Privacy Framework June 2026
* the Attestation Result claims or predicates that can be proven
without disclosure;
* the public inputs available to the Relying Party;
* the trust anchors and issuer keys used to validate the proof;
* the freshness, audience, and replay-protection mechanisms;
* the mapping between RATS Appraisal Policies for Attestation
Results and proof predicates; and
* any residual metadata that remains visible outside the proof.
ZKPs provide the strongest privacy benefit when the Relying Party can
make its decision from predicates rather than values. They also
introduce implementation complexity and can raise performance
questions. Deployments SHOULD use ZKPs for high-sensitivity claims
and MAY use Selective Disclosure as a simpler mechanism where
predicate proofs are not required.
4.6. Relationship to Privacy Pass
Privacy Pass [RFC9576] is an architecture for privacy-preserving
authorization in which a Client obtains tokens through an issuance
protocol and later redeems those tokens to an Origin.
The Origin can authorize the Client based on a valid token without
receiving unique per-Client information through the redemption
protocol and without linking redemption to the issuance interaction.
The Privacy Pass HTTP authentication scheme [RFC9577] defines the
challenge and redemption mechanism, and the Privacy Pass issuance
protocols [RFC9578] define token issuance variants based on VOPRF
[RFC9497] and Blind RSA [RFC9474] mechanisms.
Privacy Pass is relevant to this framework because it demonstrates a
deployment pattern in which detailed attestation information is used
before issuance, while the party making the authorization decision
receives only a privacy-preserving token. In RATS terms, this is
similar to using a minimized Attestation Result or a proof of a
policy predicate instead of disclosing Evidence or detailed appraisal
results to the Relying Party.
RFC 9576 maps Privacy Pass Clients to the RATS Attester role and
Privacy Pass Attesters to the RATS Verifier role; the Privacy Pass
Origin is analogous to a Relying Party that consumes the resulting
token for authorization.
Ounsworth, et al. Expires 20 December 2026 [Page 14]
Internet-Draft RATS Privacy Framework June 2026
This document does not require Privacy Pass, and a Privacy Pass token
is not a general-purpose Attestation Result unless a profile defines
the corresponding semantics, issuer trust model, freshness, audience
restriction, and claim or predicate meaning. Existing Privacy Pass
tokens are primarily authorization tokens proving that issuance
occurred under an accepted issuance policy, whereas RATS Attestation
Results can carry richer appraised state, policy identifiers,
assurance levels, or proofs over specific claims. Nevertheless,
profiles of this framework can use Privacy Pass as a design
reference, or potentially as a concrete mechanism, when the Relying
Party only needs to know that an Attester satisfied an issuer policy
and does not need the underlying Evidence or claim values.
The privacy properties depend on the deployment model. As in Privacy
Pass, separation between the party that observes detailed attestation
information and the party that redeems the token can improve
unlinkability, while collusion, small anonymity sets, issuer
selection, token metadata, timing, network identifiers, or overly
specific challenges can weaken it. Profiles using Privacy Pass-style
tokens therefore still need the minimization, audience restriction,
freshness, replay protection, and metadata guidance described in this
document.
5. Security Considerations
This document relies on the security of the underlying RATS
architecture [RFC9334], Evidence formats, Attestation Result formats,
object security mechanisms, and transport protocols.
Encrypting Evidence for the Verifier protects confidentiality but
does not by itself prove that the Verifier is authorized to receive
the requested claims. Attesters and Presenters MUST authenticate the
Verifier's encryption credential and check it against the applicable
trust anchor store and claim-category authorization policy before
releasing sensitive Evidence. Furthermore, this provides only
implicit authentication of the Verifier under the assumption that
only a Verifier in possession of the corresponding private key will
be able to decrypt the Evidence instead of an explicit authentication
step prior to transmitting the Evidence. For most deployments, this
difference will be inconsequential.
Evidence encryption needs integrity and context binding. If a
ciphertext can be replayed, redirected to a different Verifier, or
detached from the Relying Party challenge that caused its creation,
then an attacker might cause stale or unintended Evidence to be
appraised. Deployments MUST provide freshness and SHOULD bind
ciphertexts to protocol context using protected headers, AAD, or
equivalent mechanisms.
Ounsworth, et al. Expires 20 December 2026 [Page 15]
Internet-Draft RATS Privacy Framework June 2026
Relying Parties might attempt to request more detail than needed,
coerce holders into revealing more selectively disclosable claims, or
correlate Attesters using stable metadata. Verifier and holder
policies SHOULD reject excessive disclosure requests.
Implementations SHOULD provide a way for the Attester, device owner,
or administrator to understand and control which Relying Parties
receive sensitive Attestation Result claims.
Selective Disclosure and ZKP-based Attestation Results require
careful algorithm agility and validation rules. Relying Parties MUST
validate issuer signatures, proof algorithms, key binding, audience,
nonce or freshness values, and claim semantics. Failure to validate
any of these can turn a privacy-preserving presentation into a
replayable bearer token or an ambiguous proof.
Object encryption and TLS do not prevent an authorized recipient from
retaining data after decryption. Deployments handling sensitive
Evidence or Attestation Results SHOULD define retention, logging, and
audit requirements for Verifiers and Relying Parties. Where the
content of the claims could be subject to legal data retention or
data handling regulations, decryption and processing of the Evidence
SHOULD be done within a contained Verifier module.
6. Privacy Considerations
The main privacy principle in this document is categorization of
claims according to sensitivity level, protection of Evidence against
passive eavesdroppers, and recipient-specific data minimization.
Each party SHOULD receive only the Evidence, Attestation Result
claims, or proof outputs needed for its role. Deployments need to
evaluate each protocol role separately because a privacy control at
one release point can be undone by excessive disclosure at a later
release point.
The Background-Check Model has greater Evidence-disclosure risk than
the Passport Model because the Relying Party is on the Evidence path.
Encrypting Evidence for the Verifier, and proper authentication of
the Verifier's encryption key against a trust store, is therefore
especially important in the Background-Check Model. However,
encrypted Evidence does not help if the Attestation Result later
reveals the same details to the Relying Party.
Attestation Results can create linkability even when they do not
contain obvious identifiers. Combinations of claim values,
credential type, issuer, issuance time, validity window, policy
identifiers, and proof metadata can become a fingerprint. In the
case where the Evidence is used to issue a credential such as an
X.509 certificate [I-D.ietf-lamps-csr-attestation], that certificate
Ounsworth, et al. Expires 20 December 2026 [Page 16]
Internet-Draft RATS Privacy Framework June 2026
acts as an Attestation Result, and the credential itself becomes a
fingerprint that can be used to link any subsequent use of the
credential back to the Attester. Profiles of this framework SHOULD
consider pairwise identifiers, short validity periods, unlinkable
presentations, selective disclosure, and ZKP-based predicates where
appropriate. Pairwise identifiers reduce correlation by using
different identifiers for different Relying Parties or audiences
instead of a globally stable Attester identifier. Short validity
periods, nonces, and audience restrictions reduce the value of an
Attestation Result as a replayable or long-lived correlation handle.
Unlinkable presentations, where supported by the selected token or
proof format, reduce the ability of Relying Parties to determine that
two presentations came from the same Attester unless that linkage is
intentionally disclosed.
Selective Disclosure and ZKP-based predicates can reduce the amount
of claim information disclosed to a Relying Party, but they do not by
themselves remove all linkability. Deployments still need to
minimize stable metadata, issuer identifiers, key-binding material,
credential type identifiers, timestamps, and proof parameters that
remain visible outside the selectively disclosed claims or proof.
7. IANA Considerations
TBD: The EKU OID id-kp-tbd-evidence-encryption needs to be registered
here
8. References
8.1. Normative References
[COSE-HPKE]
Tschofenig, H., Jones, M. B., Steele, O., Daisuke, A., and
L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE)
with CBOR Object Signing and Encryption (COSE)", Work in
Progress, Internet-Draft, draft-ietf-cose-hpke-25, 7 April
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
cose-hpke-25>.
[JOSE-HPKE]
Reddy.K, T., Tschofenig, H., Banerjee, A., Steele, O., and
M. B. Jones, "Use of Hybrid Public Key Encryption (HPKE)
with JSON Web Encryption (JWE)", Work in Progress,
Internet-Draft, draft-ietf-jose-hpke-encrypt-20, 15 June
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
jose-hpke-encrypt-20>.
Ounsworth, et al. Expires 20 December 2026 [Page 17]
Internet-Draft RATS Privacy Framework June 2026
[JPA] Jones, M. B., Waite, D., and J. Miller, "JSON Proof
Algorithms", Work in Progress, Internet-Draft, draft-ietf-
jose-json-proof-algorithms-13, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-
json-proof-algorithms-13>.
[JPT] Jones, M. B., Waite, D., and J. Miller, "JSON Proof Token
and CBOR Proof Token", Work in Progress, Internet-Draft,
draft-ietf-jose-json-proof-token-13, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-
json-proof-token-13>.
[JWP] Waite, D., Jones, M. B., and J. Miller, "JSON Web Proof",
Work in Progress, Internet-Draft, draft-ietf-jose-json-
web-proof-13, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-
json-web-proof-13>.
[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>.
[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>.
[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>.
[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/rfc/rfc9711>.
[SD-CWT] Prorock, M., Steele, O., Birkholz, H., and R. Mahy,
"Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in
Progress, Internet-Draft, draft-ietf-spice-sd-cwt-08, 1
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-spice-sd-cwt-08>.
[SD-JWT] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/rfc/rfc9901>.
Ounsworth, et al. Expires 20 December 2026 [Page 18]
Internet-Draft RATS Privacy Framework June 2026
8.2. Informative References
[CMW] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
11 December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-23>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-28, 16
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-csr-attestation-28>.
[IAB-Statement-2023]
Internet Architecture Board, "IAB Statement on the Risks
of Attestation of Software and Hardware on the Open
Internet", n.d., <https://datatracker.ietf.org/doc/
statement-iab-statement-on-the-risks-of-attestation-of-
software-and-hardware-on-the-open-internet/>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
<https://www.rfc-editor.org/rfc/rfc5914>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
Ounsworth, et al. Expires 20 December 2026 [Page 19]
Internet-Draft RATS Privacy Framework June 2026
[RFC9474] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
Signatures", RFC 9474, DOI 10.17487/RFC9474, October 2023,
<https://www.rfc-editor.org/rfc/rfc9474>.
[RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
December 2023, <https://www.rfc-editor.org/rfc/rfc9497>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/rfc/rfc9576>.
[RFC9577] Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
HTTP Authentication Scheme", RFC 9577,
DOI 10.17487/RFC9577, June 2024,
<https://www.rfc-editor.org/rfc/rfc9577>.
[RFC9578] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
"Privacy Pass Issuance Protocols", RFC 9578,
DOI 10.17487/RFC9578, June 2024,
<https://www.rfc-editor.org/rfc/rfc9578>.
[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/rfc/rfc9597>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Mike Ounsworth
Cryptic Forest Software
Email: mike@ounsworth.ca
Hannes Tschofenig
University of the Bundeswehr Munich
Email: hannes.tschofenig@gmx.net
Guiliano Lehmann
University of Applied Sciences Bonn-Rhein-Sieg
Email: guiliano.lehmann@smail.inf.h-brs.de
Ounsworth, et al. Expires 20 December 2026 [Page 20]