Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence
draft-winmagic-wimse-condition-bounded-credentials-01
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-06 | ||
| 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-01
WIMSE T. Nguyen-Huu
Internet-Draft S. Nikitin
Intended status: Standards Track J. O'Leary
Expires: 7 January 2027 WinMagic
July 2026
Condition-Bounded Credentials for Workload and Agent Identity: Non-
Exfiltratable Keys and Validity by Presence
draft-winmagic-wimse-condition-bounded-credentials-01
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 7 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 2 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. Relationship to the WIMSE Architecture . . . . . . . . . . . 6
5. What This Profile Changes . . . . . . . . . . . . . . . . . . 7
6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
7. Credential Claims . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Authority . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Live Instance . . . . . . . . . . . . . . . . . . . . . . 9
7.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . 10
8. Verifier Contract . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Appraisal Timing . . . . . . . . . . . . . . . . . . . . 12
9. Binding to TLS Authentication . . . . . . . . . . . . . . . . 12
10. Attestation and Policy Binding . . . . . . . . . . . . . . . 13
11. Failure Behavior . . . . . . . . . . . . . . . . . . . . . . 14
12. AI Agents and Delegation . . . . . . . . . . . . . . . . . . 15
13. Applicability and Non-Goals . . . . . . . . . . . . . . . . . 16
14. Relationship to Existing Work . . . . . . . . . . . . . . . . 16
Nguyen-Huu, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Condition-Bounded Credentials July 2026
15. Security Considerations . . . . . . . . . . . . . . . . . . . 17
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
18. Design Questions for Future Versions . . . . . . . . . . . . 19
19. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . 20
20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
22.1. Normative References . . . . . . . . . . . . . . . . . . 21
22.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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?
Nguyen-Huu, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Condition-Bounded Credentials July 2026
2. Instance: is this the live endpoint or instance participating
now?
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
Nguyen-Huu, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Condition-Bounded Credentials July 2026
* a single TPM object template, TEE profile, or hardware-key recipe.
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 13.
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 7 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. Relationship to the WIMSE Architecture
This profile is defined within the WIMSE architecture
[I-D.ietf-wimse-arch] and adds no new identity model. It uses the
architecture's entities as given: a trust domain administered by a
single authority; a workload identifier naming an actor within that
domain; a Workload Identity Credential (WIC) that binds the
identifier to a key; the credential service that issues the WIC; and
the relying party that consumes it. On the mutual-TLS path
[I-D.ietf-wimse-mutual-tls], proof of possession of the WIC's key is
what authenticates the workload to the relying party.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Condition-Bounded Credentials July 2026
Within that model, this profile constrains only two things the
architecture leaves to the implementation: how the WIC's binding key
is protected, and what governs the credential's validity. It
requires the key to be non-exfiltratable and its use to be condition-
gated, and it replaces fixed-lifetime validity with validity by
presence. It does not change how identifiers are assigned, how the
WIC is issued, how trust domains federate, or how authority is
represented. Every property this document adds is stated as a
constraint on the key and its validity within the existing
architecture, not as a new component beside it.
Two axes are kept separate throughout, because conflating them is the
source of most confusion about what this profile removes. The first
axis is key safety: whether the binding key is still safe to use.
The second is the credential's identifier and metadata: what the WIC
names and asserts. This profile addresses the first axis and frees
it from clock-based rotation, because a non-exfiltratable, condition-
gated key is safe by construction while its conditions hold. It does
not free the second: assignment, reassessment, and rotation of the
WIC's identifier and metadata remain whatever the deployment's
identity model specifies. "No rotation for key safety" is not "no
rotation at all."
5. 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.
* *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. The entity that assesses the local
condition and the entity that withdraws the key are the same
Nguyen-Huu, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Condition-Bounded Credentials July 2026
entity -- the endpoint -- so validity ends by absence at the
source, with no message that must travel to a relying party or
that can go stale in transit. A relying party performing
destination-side verification can judge a condition but cannot
withdraw the key; only at the source is the assessor also the
withdrawer. Externally originated changes to a still-present
workload's authority are handled separately (Section 11 and
Section 15).
* *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 7), the verifier contract those claims are checked against
(Section 8), and how the properties above are carried, attested, and
failed closed.
6. 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 7 January 2027 [Page 8]
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?
7. Credential Claims
This document separates three claims that are often conflated.
7.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?
7.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 7 January 2027 [Page 9]
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?
7.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?
8. 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 7 January 2027 [Page 10]
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 7 January 2027 [Page 11]
Internet-Draft Condition-Bounded Credentials July 2026
8.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.
9. 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 11 and
Section 15.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 12]
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.
10. 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 7 January 2027 [Page 13]
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 15. This document requires the profile to expose the
verifier-facing semantics of that construction, not to standardize
one hardware recipe.
Non-exfiltratability is best understood as a property of an enforced
boundary rather than of the key itself: the private key cannot exist
in usable form outside a boundary whose integrity is enforced. What
supplies that boundary is deployment-specific. A hardware security
element such as a TPM or TEE supplies it for an on-device actor; a
confidential-computing environment supplies it for a workload that
has no dedicated physical device of its own. The model is the same
in both settings; only the boundary technology differs, which is why
this document constrains the boundary's verifier-facing properties
rather than naming a primitive. One requirement follows directly and
MUST hold in any profile: the boundary must be enforced, not
asserted. If a copy of the key can exist and be used outside the
boundary while still being treated as the same key, then an
attacker's copy is also the same key, and the non-exfiltratability
property is lost. A profile MUST specify how the boundary is
enforced and how a verifier gains evidence of that enforcement.
11. 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;
Nguyen-Huu, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Condition-Bounded Credentials July 2026
* 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.
Enforcement by key absence acts at the next use of the key: the next
handshake, key agreement, or signing operation cannot complete once a
required condition has failed. It does not, by itself, tear down a
connection that is already open, because an established connection
does not re-exercise the binding key while it runs. This is the same
boundary a rotated certificate has -- expiry or revocation also acts
only at the next handshake, not inside a live connection -- so it is
a property of connection-oriented transport, not a weakness specific
to this profile. Where a deployment requires a long-lived connection
to be terminated immediately upon a condition change, that behavior
is a separate, explicitly specified control: bounding the maximum
connection lifetime so that re-authentication recurs, driving
teardown from the external signal of Section 15, or both. A profile
that permits long-lived connections SHOULD state which of these it
relies on, and MUST NOT represent the possession proof at connection
setup as continuing evidence that the condition still holds later in
the connection's life.
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.
12. 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
Nguyen-Huu, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Condition-Bounded Credentials July 2026
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.
13. 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.
14. 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.
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.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Condition-Bounded Credentials July 2026
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.
This profile is an authentication input, not an authorization one.
Its possession-under-condition proof establishes that the genuine,
present actor holds the key at the transport; it deliberately does
not establish delegated authority, human authorization, operation
scope, or the sufficiency of an action. Those are separate inputs,
supplied by separate mechanisms and carrying separate failure
classes: a delegation-chain mechanism supplies the conveyed-and-
narrowed authority path, and an offline-verifiable human-
authorization receipt supplies pre-execution approval by a named
human. Such inputs compose with this profile rather than being
provided by it: they depend on the possession proof for holder
binding at the transport, while this profile depends on none of them.
In a composed decision the inputs are conjunctive and joined on a
shared action digest, and each fails independently, so no layer
inherits another's guarantees. A layered mapping of how a possession
row, a delegation-chain row, and a human-authorization row are stated
and composed against a common set of requirements is recorded in
[I-D.rampalli-cross-org-delegation-mapping]; a delegation-chain
mechanism of the kind referenced there is described in
[I-D.rampalli-pedigree].
15. 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;
Nguyen-Huu, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Condition-Bounded Credentials July 2026
* 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.
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.
Virtualized platforms. Where the boundary is supplied by a virtual
device such as a vTPM rather than a discrete physical element, the
boundary's state can be captured and moved with the virtual machine
-- for example in a snapshot, clone, or live migration -- which would
carry the protected key with it and defeat non-exfiltratability. The
non-exfiltratability guarantee therefore holds only if the virtual
boundary is anchored to the specific instance and protected against
rollback, so that the key cannot be revived in a copied or reverted
instance. A profile that permits a virtual boundary MUST state how
the boundary is bound to the instance and how rollback is prevented;
absent that, the guarantee degrades to the protection of the
snapshot, which is a weaker property and must not be presented as
hardware non-exfiltratability.
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.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Condition-Bounded Credentials July 2026
16. 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.
17. IANA Considerations
This document has no IANA actions.
18. 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?
Nguyen-Huu, et al. Expires 7 January 2027 [Page 19]
Internet-Draft Condition-Bounded Credentials July 2026
19. Changes from -00
This revision adds material and does not alter the -00 model:
* a new section grounding the profile in the WIMSE architecture
(trust domain, workload identifier, WIC, credential service,
relying party) before any new property is named, and separating
the key-safety axis from the identifier-and-metadata axis;
* a statement of the failure-enforcement property in source terms:
the assessor of the local condition and the withdrawer of the key
are the same entity, so validity ends by absence with no message
to travel or go stale;
* treatment of the already-open long-lived connection in Section 11:
key absence acts at the next key use, immediate teardown of a live
connection is a separately specified control, and the boundary is
shared with certificate rotation;
* a boundary-property framing of non-exfiltratability in Section 10
(enforced boundary, not key; hardware or confidential computing
supplies it; enforced, not asserted);
* a virtualized-platform caveat in Section 15 on vTPM snapshot and
rollback, requiring instance binding and rollback protection;
* positioning in Section 14 of this profile as an authentication
input that composes with, and does not provide, delegated-
authority and human-authorization inputs joined on a shared action
digest; and
* informative references for the WIMSE architecture, a layered
requirements mapping, and a delegation-chain mechanism.
20. 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
21. 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.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 20]
Internet-Draft Condition-Bounded Credentials July 2026
22. References
22.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/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>.
22.2. Informative References
[I-D.ietf-wimse-arch]
IETF WIMSE Working Group, "WIMSE Architecture", Work in
Progress, Internet-Draft, draft-ietf-wimse-arch, 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
[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.rampalli-cross-org-delegation-mapping]
IETF Internet-Draft, "A Layered Requirements Mapping for
Cross-Organization Agent Delegation", Work in Progress,
Internet-Draft, draft-rampalli-cross-org-delegation-
mapping, 2026, <https://datatracker.ietf.org/doc/draft-
rampalli-cross-org-delegation-mapping/>.
Nguyen-Huu, et al. Expires 7 January 2027 [Page 21]
Internet-Draft Condition-Bounded Credentials July 2026
[I-D.rampalli-pedigree]
IETF Internet-Draft, "PEDIGREE: Verifiable Delegation
Identity for Agentic AI Systems", Work in Progress,
Internet-Draft, draft-rampalli-pedigree, 2026,
<https://datatracker.ietf.org/doc/draft-rampalli-
pedigree/>.
[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>.
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 7 January 2027 [Page 22]