Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence
draft-winmagic-wimse-condition-bounded-credentials-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 | Thi Nguyen Huu , Sergei Nikitin , John O'Leary | ||
| Last updated | 2026-07-03 | ||
| 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-winmagic-wimse-condition-bounded-credentials-00
WIMSE T. Nguyen-Huu
Internet-Draft S. Nikitin
Intended status: Standards Track J. O'Leary
Expires: 3 January 2027 WinMagic
2 July 2026
Condition-Bounded Credentials for Workload and Agent Identity: Non-
Exfiltratable Keys and Validity by Presence
draft-winmagic-wimse-condition-bounded-credentials-00
Abstract
The WIMSE architecture binds a workload credential to a cryptographic
key presented with proof of possession, and leaves credential
lifetime and rotation to the implementation. In common practice the
binding key is held in software and rotated frequently, because a
software key can be copied: rotation is a compensating control for a
key that can be exfiltrated.
This document defines a profile in which the binding key is hardware-
rooted and non-exfiltratable, and in which credential validity is
gated by attested conditions -- the workload and its required posture
being measured and present -- rather than by a fixed expiry. Two
consequences follow. Frequent rotation is no longer required to
bound exfiltration, because the key cannot leave the hardware
boundary. And a grant cannot outlive the workload, even with no
expiry date, because the key, and with it the ability to prove
possession, is gone once the workload or its conditions cease to
hold. Condition failure is therefore enforced by the key's absence
rather than by a revocation message, and the credential can be
appraised without a live connection to its issuing authority.
The profile is specified against a verifier contract -- authority,
live-instance, condition, freshness, and fail-closed checks -- that
other credential profiles can share, so these properties are made
explicit and reviewable without standardizing a single credential
format or hardware recipe. It is offered as one conforming way to
instantiate WIMSE credentials, suited to stable, attestable
platforms, and is explicitly not proposed for high-churn, hardware-
less workloads.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 1]
Internet-Draft Condition-Bounded Credentials July 2026
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 3 January 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
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. What This Profile Changes . . . . . . . . . . . . . . . . . . 6
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
6. Credential Claims . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Live Instance . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . 9
7. Verifier Contract . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Appraisal Timing . . . . . . . . . . . . . . . . . . . . 11
8. Binding to TLS Authentication . . . . . . . . . . . . . . . . 11
9. Attestation and Policy Binding . . . . . . . . . . . . . . . 12
10. Failure Behavior . . . . . . . . . . . . . . . . . . . . . . 13
11. AI Agents and Delegation . . . . . . . . . . . . . . . . . . 14
12. Applicability and Non-Goals . . . . . . . . . . . . . . . . . 14
13. Relationship to Existing Work . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Nguyen-Huu, et al. Expires 3 January 2027 [Page 2]
Internet-Draft Condition-Bounded Credentials July 2026
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
17. Design Questions for Future Versions . . . . . . . . . . . . 17
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
20.1. Normative References . . . . . . . . . . . . . . . . . . 17
20.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The WIMSE architecture establishes two load-bearing protections for
workload credentials: cryptographic key-binding with proof of
possession, so that a credential cannot be used as a bearer token;
and least privilege, to limit the authority any single credential
conveys. The architecture is deliberately broad about how
credentials are provisioned, and it does not say how long the binding
key should live or how often it should be replaced.
In widely deployed implementations the binding key is held in
software, is short-lived, and is rotated automatically. The purpose
of the short lifetime is to bound the exposure of a key that might be
leaked or compromised: rotation is a compensating control for a key
that can be exfiltrated.
This document observes that the compensating control and the
condition it compensates for can be removed together. If the binding
key cannot be extracted from the workload's hardware, and if it
exists only while the workload and its policy conditions hold, then
rotating the key to bound exfiltration is no longer required --
exfiltration is prevented at the boundary rather than time-limited --
and a grant exercised with that key cannot outlive the workload, even
with no expiry date, because the ability to prove possession is gone
once the conditions fail. The result is a credential whose validity
tracks the attested presence of the workload rather than a clock.
The property is not workload-specific. The same reasoning applies
wherever an actor's key can be hardware-bound and condition-gated,
including AI agents, human-operated endpoints, and machine or
operational-technology systems. Accordingly this document keeps the
actor slot generic and separates three questions a relying party may
need to answer:
1. Authority: who is authorized to act or be represented?
2. Instance: is this the live endpoint or instance participating
now?
Nguyen-Huu, et al. Expires 3 January 2027 [Page 3]
Internet-Draft Condition-Bounded Credentials July 2026
3. Conditions: are the relevant platform, posture, or authorization
conditions satisfied at the time of use?
The profile is specified against a common verifier contract for these
three questions, so that the properties above are stated as checks a
verifier can perform rather than as claims a vendor makes. The
construction is not intended to replace existing credential types; it
is one conforming way to instantiate WIMSE credentials on the mutual-
TLS path, and it coexists with rotating, software-keyed credentials
for workloads where those are the right tool.
1.1. Goals
* Make non-exfiltratability and condition-bounded validity (validity
by presence) explicit, reviewable properties of a credential.
* Separate authority, live-instance, and condition claims.
* Define a verifier-facing contract for accepting condition-bounded
credential use.
* Identify the evidence needed to make key-use policy verifier-
observable.
* Describe how the model is carried by TLS authentication.
* Define failure behavior for missing, stale, or inconsistent
evidence, including enforcement by key absence.
1.2. Non-Goals
This document does not attempt to standardize all deployment details
in its initial form. In particular, this document does not define:
* a universal credential format;
* a universal policy language;
* a single mandatory attestation evidence format;
* a replacement for WIMSE workload identity, OAuth, SPIFFE, X.509,
vLEI, Verifiable Credentials, or RATS;
* deployment-specific platform measurements or posture signals; or
* a single TPM object template, TEE profile, or hardware-key recipe.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 4]
Internet-Draft Condition-Bounded Credentials July 2026
The profile is also not proposed for high-churn, ephemeral, hardware-
less workloads, where short-lived, software-keyed credentials remain
the appropriate tool. Applicability is stated in Section 12.
2. Requirements Language
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. Terminology
This document uses WIMSE and RATS terminology (Workload, Workload
Identifier, Workload Identity Credential, Proof of Possession,
Attestation; Evidence, Verifier, Relying Party, Attestation Result)
while keeping the actor slot generic. In addition:
Actor
The entity or role being authorized. The actor may be a workload,
service, agent, human operator, device, or machine.
Platform
The hardware, firmware, operating environment, or execution
environment in which the actor's credential key is created,
protected, loaded, or used.
Protected Key
A private key whose extraction is prevented or constrained by
hardware, firmware, a TEE, a TPM, or an equivalent local
protection mechanism. The exact primitive is deployment-specific
unless a profile defines it.
Non-Exfiltratable Key
A protected key generated and used inside a hardware security
boundary such that the private key material is never available to
the operating system, the application, or any other software, and
cannot be copied off the device. Signing occurs inside the
boundary.
Condition
A policy predicate that must be satisfied before the protected key
can be used. Conditions can include device state, measured
software state, posture state, authorization state, freshness
state, time state, or deployment-defined local state.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 5]
Internet-Draft Condition-Bounded Credentials July 2026
Presence
The continuously evaluable state in which all conditions required
for the key to be usable currently hold.
Condition-Bounded Validity (Validity by Presence)
A property whereby a credential's binding key is usable only while
a defined set of attested conditions holds. When any required
condition fails, the key ceases to be usable for the next
operation. Validity is the existence of a usable key, not a date
carried within the credential.
Condition-Bounded Credential
A credential profile in which successful use of the credential's
protected key is conditioned on a key-use policy, evidence about
that policy is available to a verifier, and validity is condition-
bounded as defined above.
Condition Evidence
Evidence or an Attestation Result that lets a verifier appraise
whether the expected key-use policy, platform state, posture
state, authorization state, or freshness rule applies to the
current credential use.
Verifier Contract
The set of checks a verifier performs before accepting a
credential use: authority validation, live-instance proof,
condition appraisal, freshness, and fail-closed behavior.
4. What This Profile Changes
The WIMSE credential-theft and workload-compromise mitigations are
key-binding and least privilege. Both are preserved and strengthened
here. The lifetime and rotation properties, which the architecture
leaves to the implementation, are where this profile differs.
* *Exfiltration.* Where the prevailing model bounds exfiltration
exposure through short key lifetime, this profile bounds it
through non-extractability. A key that cannot leave the boundary
has no exfiltration window to bound.
* *Grant lifetime.* Where the prevailing model limits a grant in
time through short credential expiry, this profile limits it
through condition-bounded validity. A grant cannot be replayed
elsewhere, because the key cannot move, and cannot outlive the
workload, because the key is gone when presence ends.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 6]
Internet-Draft Condition-Bounded Credentials July 2026
* *Enforcement of failure.* Because a workload session depends on
repeated use of the key, the loss of a required condition makes
the key unusable for the next operation. Condition failure is
therefore enforced by the key's absence: there is no credential
left to present and no revocation message that must travel for
enforcement to take effect. Externally originated changes to a
still-present workload's authority are handled separately
(Section 10 and Section 14).
* *Independence from a live issuer.* Because validity is the present
usability of the key rather than a signed lifetime, a verifier can
appraise the credential without a live connection to the issuing
authority at the time of use. This lets the profile operate in
disconnected, intermittently connected, and air-gapped
environments, where a credential that must be rotated before
expiry cannot.
This is offered as an alternative instantiation, not a correction.
The two models coexist: a deployment may issue rotating, software-
keyed credentials for some workloads and condition-bounded, hardware-
keyed credentials for others, under one identifier scheme. The
remainder of this document states the claims a verifier separates
(Section 6), the verifier contract those claims are checked against
(Section 7), and how the properties above are carried, attested, and
failed closed.
5. Problem Statement
Many identity mechanisms prove authority but leave live-instance and
current-condition properties implicit. For example, a credential
chain may show that an issuer authorized a subject, but the relying
party may still not know whether:
* the private key is non-extractable;
* the key is currently being used by the enrolled platform;
* the key was usable only when required posture or authorization
conditions were satisfied;
* the verifier has fresh evidence of those conditions; or
* failure of any of those checks causes the request or channel to
fail closed.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 7]
Internet-Draft Condition-Bounded Credentials July 2026
Without a common model for these checks, specifications can use
phrases such as "identity at the wire", "live agent", "authorized
workload", or "trusted endpoint" while leaving implementers to infer
which property is actually being claimed and which protocol check
enforces it.
The problem for WIMSE is therefore not only credential
representation. It is the verifier-facing semantics of a credential
use:
* What authority issued or registered the credential?
* Which endpoint proved possession of the protected key?
* What policy constrained use of that key?
* What evidence lets the verifier appraise that policy?
* What happens when evidence is stale, missing, or inconsistent?
6. Credential Claims
This document separates three claims that are often conflated.
6.1. Authority
The authority claim identifies who authorized the actor, principal,
or credential. This may be established through a credential chain,
registration record, vLEI-style authority credential, workload
identity issuer, X.509 trust anchor, Verifiable Credential issuer, or
other configured trust root.
A verifier accepting the authority claim answers: Is this actor,
principal, or credential authorized by a trust root accepted by the
relying party for this purpose?
6.2. Live Instance
The live-instance claim establishes that the endpoint participating
in the current protocol exchange possesses the protected key
associated with the registered credential.
In TLS, this can be shown by authentication using the protected
private key. The public key can be carried in an X.509 certificate
or, in deployments with out-of-band enrollment, as a raw public key.
If raw public keys are used, the profile should align with [RFC7250].
Nguyen-Huu, et al. Expires 3 January 2027 [Page 8]
Internet-Draft Condition-Bounded Credentials July 2026
A verifier accepting the live-instance claim answers: Did the current
protocol peer prove possession of the registered protected key in
this exchange?
6.3. Conditions
The condition claim establishes that use of the protected key was
constrained by a policy and that evidence about this policy can be
appraised.
The key point is that possession alone is not enough. A verifier
also needs to know what made the key usable. For example, the
relying party may need evidence that key use was conditioned on a
measured platform state, device posture, authorization grant,
freshness value, or other deployment-defined predicate.
RATS terminology from [RFC9334] is useful here because it separates
Evidence, appraisal policy, Verifier, Relying Party, and Attestation
Results. This document reuses that separation rather than defining a
new attestation model.
A verifier accepting the condition claim answers: Was the protected
key usable only under conditions accepted by the relying party, and
is the evidence for that key-use policy fresh enough and verifier-
observable?
7. Verifier Contract
A condition-bounded credential is accepted only if the verifier can
establish all of the following:
1. Authority check: the actor or credential is authorized by an
accepted trust root or enrollment record.
2. Instance check: the current endpoint proves possession of the
registered protected key in the current protocol exchange.
3. Condition check: evidence shows that key use is constrained by
the expected key-use policy, and that the policy is tied to
expected platform, posture, authorization, or freshness
conditions.
4. Freshness check: the evidence or Attestation Result is
sufficiently fresh for the relying party's policy.
5. Failure behavior: if any required check fails, the channel,
request, or credential use fails closed.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 9]
Internet-Draft Condition-Bounded Credentials July 2026
The verifier contract is the main interoperability surface of this
document. Different deployments may use different evidence formats,
protected-key technologies, or credential carriers, but they should
be able to describe the same logical checks. In a condition-bounded
profile, the instance and condition checks are coupled: a successful
proof of possession is only produced by a key that is presently
usable, so a passing instance check is itself evidence that the key-
use conditions currently hold.
A profile that claims to implement this model MUST specify how each
verifier-contract check is performed, what evidence is visible to the
verifier, what conditions are enforced only by the local platform,
and what freshness rule applies to the evidence or Attestation
Result. A verifier MUST reject the credential use when required
evidence is missing, stale, inconsistent with the credential, or
inconsistent with the expected key-use policy.
+------------------+
| Authority Source |
+---------+--------+
|
v
+---------+ +-------+--------+ +-------------------+
| Actor / |---->| Credential Use |----->| Relying Party |
|Endpoint | | in Protocol | | Decision |
+----+----+ +-------+--------+ +---------+---------+
| | ^
| v |
| +-------+--------+ |
+--------->| Verifier |----------------+
| Contract |
+-------+--------+
^
|
+---------+---------+
| Condition Evidence|
| and Appraisal |
+-------------------+
Figure 1: Condition-Bounded Credential Verifier Contract
Nguyen-Huu, et al. Expires 3 January 2027 [Page 10]
Internet-Draft Condition-Bounded Credentials July 2026
7.1. Appraisal Timing
The verifier contract can be instantiated at enrollment time,
connection time, request time, or through periodic re-attestation. A
profile MUST state which timing model it uses and whether stale or
missing condition evidence causes the credential use to fail. When
the credential use opens a channel, the profile should define whether
application data is withheld until the authority, instance,
condition, and freshness checks have succeeded.
Because validity is the present usability of the key, condition
appraisal at the time of use does not require a live connection to
the issuing authority. A profile MAY rely on evidence established at
enrollment or re-attestation together with the live proof of
possession, which is what allows operation in disconnected or
intermittently connected environments.
8. Binding to TLS Authentication
This document describes a TLS-oriented binding model without
requiring a single credential carrier. Two carriers are plausible:
* X.509: the protected public key is represented in a certificate,
and normal TLS certificate authentication proves possession of the
corresponding private key.
* Raw Public Key: the public key is registered out of band and
carried or negotiated using TLS raw public key mechanisms such as
[RFC7250].
On the mutual-TLS path in scope here, the TLS CertificateVerify
signature is produced inside the hardware boundary, so the key proves
possession in the handshake and is never exposed. Trust
establishment and key protection are kept as two independent axes:
where relying parties can be pre-provisioned with the identifier-to-
key binding, or resolve it out of band, a certificate is OPTIONAL.
Where a certificate is used, it MAY be long-lived, because it is
inert without the live key and therefore performs no revocation
function through its dates. This concerns only possession and use of
the protected key: authority withdrawal, device retirement, and
attestation-root change are not addressed by certificate dates and
still use the external lifecycle path described in Section 10 and
Section 14.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 11]
Internet-Draft Condition-Bounded Credentials July 2026
In either carrier, the TLS proof of possession establishes only the
live-instance property. It does not by itself establish the
condition property. The condition property requires evidence that
the key-use policy is bound to the expected platform or posture
state.
This separation avoids overclaiming. "The key was used in TLS" is
not the same as "the key was usable only under the required
conditions".
A raw public key profile fits deployments where the relying party
maintains an enrollment record for the protected public key and does
not need an X.509 certification path for the authority claim. An
X.509 profile fits deployments where the public key is carried in a
certificate and normal certificate-path processing contributes to the
authority check. In both cases, condition evidence can be carried
outside the certificate or represented by a profile-defined
extension, but the profile must define how the evidence is associated
with the key proven in the TLS exchange.
9. Attestation and Policy Binding
The condition property depends on evidence. This document does not
require a single attestation technology, but it defines the minimum
information a verifier needs:
* identity of the protected key or public key;
* identity of the platform or protection environment;
* key-use or key-release policy;
* measurement, posture, or authorization predicates;
* freshness information;
* appraisal result or verifier decision; and
* policy version or configuration identity when relevant.
The verifier needs evidence that the key-use policy is the policy the
relying party intends to rely on. If the policy is deployment-
defined and cannot be observed by the verifier, the condition claim
is only an assertion. Where an attestation service already exists --
for example a SPIRE deployment or a measured-state attestor -- a
profile SHOULD consume its evidence rather than reimplement
attestation.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 12]
Internet-Draft Condition-Bounded Credentials July 2026
The exact protected-key primitive is intentionally profile-specific.
A profile might use a TPM-resident signing key, policy-authorized key
use, a key released by a local policy mechanism, a TEE-protected key,
or another non-extractable protected-key construction. A profile MAY
bind key use to the expected measured platform state, so that the key
is usable only while that state holds -- a stronger statement than
attesting the workload and then issuing a separate, independently
held key. The strength of that binding, and the fidelity of the
measured state to the software actually running, are addressed in
Section 14. This document requires the profile to expose the
verifier-facing semantics of that construction, not to standardize
one hardware recipe.
10. Failure Behavior
Profiles of this model SHOULD define fail-closed behavior for at
least these cases:
* authority validation fails;
* proof of possession fails;
* evidence is missing;
* evidence is stale;
* evidence does not refer to the expected key;
* evidence does not bind the key-use policy to the expected platform
state;
* appraisal policy rejects the platform or posture state; or
* the verifier cannot determine whether the current use is within
policy.
Two enforcement paths SHOULD be distinguished. When a required
condition fails locally, the protected key becomes unusable for the
next operation; the credential use then fails because there is no
usable key to prove possession, with no revocation message required.
When a still-present workload's authority is narrowed externally --
for example, a policy change revoking one permission while posture is
unchanged -- enforcement does not depend on credential expiry and is
delivered out of band, for example by a continuous-evaluation signal
such as CAEP or an equivalent deployment-specific mechanism. A
profile MUST state which conditions are enforced by key absence and
which are enforced by an external signal.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 13]
Internet-Draft Condition-Bounded Credentials July 2026
If the credential is used to open a channel, failure should abort the
channel or prevent protected application data from being released.
If the credential is used to authorize an application request,
failure should reject the request.
11. AI Agents and Delegation
For an agent acting on behalf of a user, this profile represents the
composite actor as the agent's workload identity bound, through the
device platform, to the user's verified presence. Where the agent is
co-located with the user on an attested endpoint, the user's
authority can be proven live at the point of action rather than
carried solely as a propagated claim, and "on behalf of whom" is
resolved locally.
Where the agent executes remotely from the user, the user's authority
is conveyed as a transient, request-scoped permission bound to the
remote instance's own non-exfiltratable key, so that an intercepted
or replayed permission is useless on any other instance. Autonomous
operation across a period of user unavailability reintroduces a
bounded pre-authorization window; this is a deliberate, scoped
exception and SHOULD be minimized.
12. Applicability and Non-Goals
This profile is appropriate for workloads running on stable,
attestable hardware: endpoints, virtual machines with a vTPM,
dedicated or persistent services, edge and operational-technology
systems, and long-lived agents. It is explicitly not proposed for
high-churn, ephemeral, hardware-less workloads -- for example,
millisecond-scale serverless fan-out sharing a node's hardware --
where a per-connection hardware signature is a throughput ceiling and
short-lived, software-keyed credentials remain the appropriate tool.
The boundary is set by connection churn and hardware availability,
and is acknowledged here rather than argued away.
13. Relationship to Existing Work
This document is intended to complement existing WIMSE workload
identity work, including WIMSE workload credentials
[I-D.ietf-wimse-workload-creds] and workload authentication using
mutual TLS [I-D.ietf-wimse-mutual-tls]. It does not replace workload
identity tokens, service-to-service authentication, OAuth, SPIFFE,
vLEI, X.509, Verifiable Credentials, or RATS. It is a credential and
validity profile under those documents, not a replacement for any of
them.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 14]
Internet-Draft Condition-Bounded Credentials July 2026
The distinct contribution is a credential whose binding key is non-
exfiltratable and whose validity is condition-bounded, specified
against a verifier contract that separates authority, live-instance,
and condition claims and can be applied across credential carriers.
With respect to SPIFFE and SPIRE, this profile is a credential and
validity model under the existing identifier model. It consumes
workload attestation where an attestation service already exists,
rather than reimplementing it, and can present a SPIFFE-compatible
interface to consumers. It is not a replacement for the SPIFFE
identity model, nor for rotation-based issuance where that model is
the right fit.
The relationship to heterogeneous credential verification
[I-D.jiang-wimse-heterogeneous-credential] should also be made
explicit. Heterogeneous credential verification concerns receiving-
side normalization and combination of multiple credential
verification results. This document instead focuses on the semantics
of one condition-bounded credential use: what claims it makes, which
checks prove them, and how failures behave.
This document is also related to work on workload attestation
[I-D.reddy-wimse-workload-attestation]. That work specifies ways to
convey attestation information in particular protocol contexts. This
document instead defines the claim structure and verifier contract
that a credential profile can use when authority, live-instance, and
current-condition claims need to be evaluated together.
14. Security Considerations
This document does not treat hardware binding as sufficient by
itself. Security depends on the complete verifier contract:
* the private key must be protected against extraction;
* the proof of possession must be bound to the current protocol
exchange;
* the condition policy must be known or appraisable by the verifier;
* evidence freshness must be enforced;
* failure must be fail-closed; and
* relying parties must not treat an authority credential as proof of
live instance or current conditions.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 15]
Internet-Draft Condition-Bounded Credentials July 2026
Posture observation. The non-extractability of the key is a hardware
guarantee. The conditions gating its use are anchored in hardware
but observed in software, and can in principle be degraded by
extraordinary deep compromise of the observing layer; this profile
does not claim otherwise.
Revocation and lifecycle. Because a locally failed condition removes
the key, enforcement of local conditions requires no revocation
message. Externally originated changes to a still-present workload
-- role removal, policy withdrawal, quarantine, device retirement, or
attestation-root change -- are carried out of band, for example by a
continuous-evaluation signal such as CAEP or an equivalent
deployment-specific mechanism, and degrade gracefully when that
signal is unavailable. A profile that uses a long-lived protected
key MUST state how policy update, posture change, and evidence
expiration are handled by these two paths.
Profiles should address at least the following threats: extracted or
duplicated key material, cloned platform state, stale condition
evidence, replayed evidence, policy rollback, enrollment-record
substitution, and confusion between authority evidence and condition
evidence. Replay protection can be provided by the protocol
exchange, by the evidence freshness mechanism, or by both, but the
profile needs to specify which mechanism is relied upon for each
verifier-contract check.
15. Privacy Considerations
Condition evidence can reveal device identity, software state,
operator state, location, or posture details. Profiles should
minimize disclosure and should avoid exposing deployment-specific
measurements unless the relying party needs them for appraisal.
Where possible, the verifier should receive an Attestation Result or
policy decision rather than raw measurement details.
A stable identifier with a long-lived key is a strong correlation
handle across an actor's actions. For governed enterprise workloads
this supports accountability and audit and is generally desirable; it
is nonetheless a deliberate trade against unlinkability, and is named
here as such. Audience- and transaction-scoping of tokens limits
cross-domain correlation. Any pre-authorization granted to cover
user or issuer unavailability is, for its duration, more token-like
and correspondingly weaker; it SHOULD be kept short and narrowly
scoped.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 16]
Internet-Draft Condition-Bounded Credentials July 2026
16. IANA Considerations
This document has no IANA actions.
17. Design Questions for Future Versions
Future versions or concrete profiles need to resolve the following
design questions:
1. Which protected-key constructions should be profiled first?
2. Should the first concrete TLS profile use raw public keys, X.509
certificates, or both?
3. Which condition-evidence formats are appropriate for
interoperable profiles?
4. Should condition appraisal be performed at enrollment, at
connection time, at request time, or through periodic re-
attestation?
5. Which state expires in each profile: credential registration,
authorization grant, key-use policy, Evidence, or Attestation
Result?
6. How should the JWT-SVID / application-token (bearer) path, out of
scope in this version, be addressed for credentials presented
outside an mTLS handshake?
18. Contributors
Songbo Bu shaped the structure and the verifier-processing model of
this document, and contributed verifier-contract text, security
review, and claim-separation analysis for the initial version.
Email: bluedognull@gmail.com
19. Acknowledgements
The authors thank Deb Cooley for suggesting that this work be brought
to WIMSE, and thank the WIMSE participants whose discussions on
workload identity, agent identity, attestation, and heterogeneous
credential verification helped motivate this work.
20. References
20.1. Normative References
Nguyen-Huu, et al. Expires 3 January 2027 [Page 17]
Internet-Draft Condition-Bounded Credentials July 2026
[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/info/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/info/rfc8174>.
20.2. Informative References
[I-D.ietf-wimse-mutual-tls]
IETF WIMSE Working Group, "WIMSE Mutual TLS", Work in
Progress, Internet-Draft, draft-ietf-wimse-mutual-tls-01,
2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-
mutual-tls/>.
[I-D.ietf-wimse-workload-creds]
IETF WIMSE Working Group, "WIMSE Workload Credentials",
Work in Progress, Internet-Draft, draft-ietf-wimse-
workload-creds-01, 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-
workload-creds/>.
[I-D.jiang-wimse-heterogeneous-credential]
IETF Internet-Draft, "Heterogeneous Credential
Verification for Workload and Agentic Systems", Work in
Progress, Internet-Draft, draft-jiang-wimse-heterogeneous-
credential-01, 2026, <https://datatracker.ietf.org/doc/
draft-jiang-wimse-heterogeneous-credential/>.
[I-D.reddy-wimse-workload-attestation]
IETF Internet-Draft, "WIMSE Workload Attestation", Work in
Progress, Internet-Draft, draft-reddy-wimse-workload-
attestation-00, 2026, <https://datatracker.ietf.org/doc/
draft-reddy-wimse-workload-attestation/>.
[RFC7250] Wouters, P., Tschofenig, H., 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/info/rfc7250>.
[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/info/rfc9334>.
Nguyen-Huu, et al. Expires 3 January 2027 [Page 18]
Internet-Draft Condition-Bounded Credentials July 2026
Authors' Addresses
Thi Nguyen-Huu
WinMagic
Email: thi.nh@winmagic.com
Sergei Nikitin
WinMagic
Email: sergei.nikitin@winmagic.com
John O'Leary
WinMagic
Email: John.OLeary@winmagic.com
Nguyen-Huu, et al. Expires 3 January 2027 [Page 19]