| Internet-Draft | Condition-Bounded Credentials | July 2026 |
| Nguyen-Huu, et al. | Expires 3 January 2027 | [Page] |
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.¶
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 3 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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:¶
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.¶
This document does not attempt to standardize all deployment details in its initial form. In particular, this document does not define:¶
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.¶
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.¶
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:¶
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. 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.¶
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:¶
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:¶
This document separates three claims that are often conflated.¶
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].¶
A verifier accepting the live-instance claim answers: Did the current protocol peer prove possession of the registered protected key in this exchange?¶
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?¶
A condition-bounded credential is accepted only if the verifier can establish all of the following:¶
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 |
+-------------------+
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.¶
This document describes a TLS-oriented binding model without requiring a single credential carrier. Two carriers are plausible:¶
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.¶
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.¶
The condition property depends on evidence. This document does not require a single attestation technology, but it defines the minimum information a verifier needs:¶
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.¶
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.¶
Profiles of this model SHOULD define fail-closed behavior for at least these cases:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 document does not treat hardware binding as sufficient by itself. Security depends on the complete verifier contract:¶
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.¶
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.¶
This document has no IANA actions.¶
Future versions or concrete profiles need to resolve the following design questions:¶
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¶
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.¶