Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence

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:

Authority: who is authorized to act or be represented?
Instance: is this the live endpoint or instance participating now?
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.

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.

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.

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 .

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 when, and only when, they appear in all capitals, as shown here.

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.
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.

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. Externally originated changes to a still-present workload's authority are handled separately ( and ).
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 (), the verifier contract those claims are checked against (), and how the properties above are carried, attested, and failed closed.

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.

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?

Credential Claims This document separates three claims that are often conflated.

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?

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 . A verifier accepting the live-instance claim answers: Did the current protocol peer prove possession of the registered protected key in this exchange?

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 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?

Verifier Contract A condition-bounded credential is accepted only if the verifier can establish all of the following:

Authority check: the actor or credential is authorized by an accepted trust root or enrollment record.
Instance check: the current endpoint proves possession of the registered protected key in the current protocol exchange.
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.
Freshness check: the evidence or Attestation Result is sufficiently fresh for the relying party's policy.
Failure behavior: if any required check fails, the channel, request, or credential use fails closed.

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.

Condition-Bounded Credential Verifier Contract | Credential Use |----->| Relying Party | |Endpoint | | in Protocol | | Decision | +----+----+ +-------+--------+ +---------+---------+ | | ^ | v | | +-------+--------+ | +--------->| Verifier |----------------+ | Contract | +-------+--------+ ^ | +---------+---------+ | Condition Evidence| | and Appraisal | +-------------------+ ]]>

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.

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 .

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 and . 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.

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. 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 . This document requires the profile to expose the verifier-facing semantics of that construction, not to standardize one hardware recipe.

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. 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.

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.

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.

Relationship to Existing Work This document is intended to complement existing WIMSE workload identity work, including WIMSE workload credentials and workload authentication using 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 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 . 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.

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.

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.

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.

IANA Considerations This document has no IANA actions.

Design Questions for Future Versions Future versions or concrete profiles need to resolve the following design questions:

Which protected-key constructions should be profiled first?
Should the first concrete TLS profile use raw public keys, X.509 certificates, or both?
Which condition-evidence formats are appropriate for interoperable profiles?
Should condition appraisal be performed at enrollment, at connection time, at request time, or through periodic re-attestation?
Which state expires in each profile: credential registration, authorization grant, key-use policy, Evidence, or Attestation Result?
How should the JWT-SVID / application-token (bearer) path, out of scope in this version, be addressed for credentials presented outside an mTLS handshake?

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

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.