Condition-Bound Keys for Mutual-TLS Client Authentication and DPoP

Introduction An access token records a decision made before it was issued. Between issuance and use the actor may have walked away, the platform may have fallen out of policy, and the authorization may have been narrowed. The token says none of this. It cannot. A signed artifact reports the moment it was signed. OAuth answers this in two ways. Sender-constraining mechanisms -- mutual-TLS client authentication with certificate-bound access tokens , and DPoP -- establish that the request comes from a holder of a particular key. Separately, short lifetimes limit how long a stale decision can be used. This is not an argument about theft. Take a token that cannot be copied at all: one actor, one platform, a credential held in exactly one place. Nothing above changes. The user can still walk away and the machine can still fall out of policy. Copying decides where a stale record can be used; it does not make the record stale. So the key is where to work. Make the key exist only while a stated set of conditions holds. When a condition fails, the key is gone, and no new proof that requires it can be made. Nothing is sent and no signal is needed. Two things follow. First, for conditions the platform itself can see -- the actor walks away, the platform falls out of policy -- revocation is by absence. The party that observes the failure is the party that withdraws the key. Conditions decided elsewhere still require a signal; that boundary is drawn in . Second, the token's lifetime stops standing in for validity. A short lifetime bounds how long a record of a past authentication can still be used. Where this key applies, that work is done by the key, and lifetime is free to be what it was meant to be: how long a permission should last. Lifetimes need not change. They are no longer what ends access. Where the actor is a verified human, there is nothing left for a login to establish or a session to remember. That case is developed in and .

Scope This document is an Applicability Statement in the sense of , Section 3.2. It specifies how existing OAuth protocol specifications are combined and constrained for a class of deployment, and defines no new protocol element: no grant type, no token format, no endpoint, no parameter, and no role. Its normative requirements are addressed to profiles that adopt it. This document specifies:

the properties a binding key must have to be condition-bound, and what a profile must state about them;
how such a key is used with the client authentication and sender-constraining mechanisms OAuth already defines;
what an authorization server can verify and what a resource server can verify, which are not the same;
the effect on tokens already issued, distinguishing bearer from sender-constrained;
failure behavior, including which conditions are enforced by key absence and which require an external signal; and
application to delegated and asynchronous flows.

This document does not define a credential format, a policy language, an attestation evidence format, or a hardware recipe, and how keys are registered is out of scope. The checks this document builds on are stated in in the form this document relies on them. The general credential and validity model from which they are drawn, and its application to workload identity within a trust domain, are specified in , which this document does not otherwise restate.

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 the terms of , , , and . In addition:

Actor: The entity whose identity the credential represents: a human verified into a platform, a workload, or an agent acting for a human. The term is used as in where an actor chain is present, and generically otherwise.
Platform: The hardware, firmware, and execution environment in which the binding key is created, protected, and used.
Condition: A policy predicate that must be satisfied for the binding key to be usable. Conditions may include measured platform state, device posture, verified presence of a human actor, authorization state, or deployment-defined local state.
Condition-Bound Key: A non-exfiltratable private key whose use is gated on a set of conditions evaluated locally at the platform, such that the key cannot produce a signature for the next operation once any required condition fails. Validity is the present usability of the key, not a date carried in a credential. The key exists only while the intended identity is verified -- typically the combination of an actor, a platform, and local policy observable at the endpoint -- and disappears when a condition no longer holds. This key is referred to as a Live Key in other published material.
Binding Key: The key to which a token or client authentication is constrained: the private key corresponding to the certificate in , or the DPoP proof key in .

What a Sender Constraint Establishes A resource server that validates a certificate-bound access token per Section 3 establishes that the client presenting the token holds the private key for the certificate whose thumbprint appears in the token's confirmation claim. A resource server that validates a DPoP proof per establishes that the presenter holds the private key for the JWK in the proof header, and that the proof is bound to this request. In both cases the established fact is possession of a key at the time of the request. What that supports is an inference: the key was issued to, or registered by, a particular client on a particular platform, and it has not moved, so the request comes from that platform. The inference is sound, and it is bounded. It does not establish that the human on whose behalf the token was issued is still there. It does not establish that the platform is still in the state it was in when the authorization decision was made. It does not establish that a policy predicate evaluated at issuance still evaluates the same way. This is structural, not a defect in either mechanism. An authorization server or resource server can check a signature because the signature is carried in the request. It cannot check the actor's continued presence or the platform's current state, because neither is carried in the request and neither can be: any assertion about them placed in the request would itself be a record made at some earlier moment, subject to the same objection. Rather than convey the condition to the verifier, this document makes it a precondition of the proof the verifier already requires. The verifier's checks do not change; what changes is what a passing check implies.

Condition-Bound Keys A binding key is condition-bound for the purposes of this document when all of the following hold:

The private key is generated and used inside a boundary from which it cannot be extracted in usable form, and signing occurs inside that boundary.
Use of the key is gated by a policy evaluated at the platform, such that the key cannot produce a new signature while any required condition is unsatisfied.
The gate is enforced rather than asserted: if a copy of the key can exist and be used outside the boundary while being treated as the same key, the property does not hold.
Evidence is available to a verifier that the key's use policy is the policy the verifier intends to rely on.

Properties 1 through 3 are properties of the platform. Property 4 is what makes the arrangement verifiable, and is discussed in . Validity in this document is the present usability of the key: the key is usable when every required condition holds, and not otherwise, so a party that obtains a proof from it has established that those conditions held when the proof was made. A profile MUST specify how the boundary is enforced, which conditions gate key use, and how a verifier obtains evidence of both. The general model and terminology are specified in . Where a deployment would otherwise hold the client's authentication key or DPoP proof key in software, it instead holds a condition-bound key. Every message flow specified by and is unchanged. What changes is that the client becomes unable to produce a new proof from the moment a condition fails. Where a proof is not required -- because a connection is already established, because it is resumed from a previous one, or because the token is a bearer token -- the key's absence has no effect. states what a profile must do about the first two; addresses the third.

Use with Existing OAuth Mechanisms

Mutual-TLS Client Authentication defines two mutual-TLS client authentication methods. In the PKI method (tls_client_auth) the authorization server validates the client's certificate chain to a trust anchor and matches a configured subject. In the self-signed method (self_signed_tls_client_auth) the authorization server does not validate a chain at all: the client registers its certificates via jwks or jwks_uri, and authentication succeeds when the certificate presented in the handshake matches one registered for that client. The self-signed method is the natural fit for a condition-bound key: it is already registration of a key, with the certificate serving as an envelope rather than as an assertion of authority by a third party. A deployment using it obtains no property from the certificate's dates or issuer, and therefore loses nothing when the key underneath is condition-bound rather than lifetime-bound. When the client's authentication key is condition-bound, a failure of any gating condition means a new mutual-TLS client authentication cannot complete. The client cannot obtain a token from the token endpoint, cannot refresh, and cannot perform token exchange on a connection established after the failure. This holds at every handshake, and not only when the authorization server chooses to re-evaluate policy. It does not hold at every request: client authentication occurs once per connection, so requests sent on a connection established while conditions held are not gated again. A profile relying on this mechanism at the token endpoint MUST address connection reuse and session resumption, per .

Certificate-Bound Access Tokens Section 3 binds an access token to the client's certificate by carrying the certificate's SHA-256 thumbprint in the cnf claim, and requires the protected resource to confirm that the certificate presented in the mutual-TLS connection matches it. Where the corresponding private key is condition-bound, the resource server's existing check acquires a second meaning at no cost. The client can only present that certificate in a completed mutual-TLS handshake if it can sign with the key, and it can only sign if the conditions hold. The thumbprint comparison is unchanged; what a successful comparison implies is not. This depends on a handshake having occurred. Where a connection is resumed rather than newly established, the certificate the resource server obtains from its TLS layer may be the one remembered from the original handshake, and the thumbprint comparison will pass without the key having been exercised. states what a profile must do about this.

DPoP binds a token to a key held by the client and requires a signed proof per request. Where the DPoP proof key is condition-bound, no new proof can be produced once a required condition fails, and the resource server rejects the request under its existing rules. A DPoP proof is bound to a request but is produced before the request is sent, so a proof signed while conditions held can be presented after they have failed. Section 11.2 addresses this directly, observing that where proofs can be pre-generated, what is demonstrated is possession of a proof rather than possession of the key. A profile using condition-bound DPoP keys MUST state the acceptance window it applies to the iat claim, and MUST treat that window as the bound on how long a failed condition can remain unenforced. A profile SHOULD require server-supplied nonces, which move the bound to a value the server controls; a profile relying on nonces for this purpose MUST NOT assume they are available, since support is optional for both the authorization server and the resource server, and MUST state its behavior where they are not. DPoP's proof travels in the HTTP message rather than in the transport channel. Two consequences follow, and the second is the more important one for this profile. The proof survives a TLS-terminating intermediary, so deployments in which the client's connection is terminated before reaching the resource server SHOULD use DPoP rather than certificate-bound access tokens. The proof is also produced once per request rather than once per connection. Mutual-TLS client authentication occurs in the handshake, and over HTTP/2 and HTTP/3 there is no protocol-legal way to repeat it within a connection: Section 9.2.3 and Section 4.4 both prohibit post-handshake authentication, the latter stating the reason -- the multiplexing those transports provide prevents a client from correlating a certificate request with the application-level event that prompted it. Condition enforcement carried by the TLS binding key is therefore bounded at per-connection granularity by the transport, not by this profile. Where a profile requires enforcement at per-request granularity, DPoP is the only mechanism OAuth defines that provides it. Both properties are properties of where the proof rides, and apply whether or not the key is condition-bound. What condition-binding adds is that the granularity of the proof becomes the granularity of enforcement.

Credential Carriers and Raw Public Keys Nothing in this profile depends on the binding key being carried in an X.509 certificate. The same protected key may be presented inside a certificate or as a raw public key under , where the peer sends a SubjectPublicKeyInfo and the identity is established by prior registration. For the self-signed method of , where no chain is validated and the authorization server already matches against registered keys, the certificate contributes nothing that registration does not already supply. This document does not propose changes to , which is specified in terms of X.509. It notes the relationship because deployments without a PKI are a principal audience for condition-bound keys, and because a profile that registers keys directly is a smaller step from the self-signed method than it may appear.

Use Beyond OAuth The key described here is not specific to OAuth, and the properties above do not depend on an authorization server being present. Three cases outside this working group are noted, without proposing changes to the specifications that govern them.

Device Bound Session Credentials binds a browser session to a key held on the device: the user agent proves possession at a refresh endpoint and receives short-lived cookies for other requests. Where that key is condition-bound, a failed condition ends the refresh rather than the request in flight, and the outstanding cookies expire without renewal. The bound on exposure is then the cookie lifetime the site already chose. For a consumer, the site's sign-in stops being a separate event. The key establishes who is present at each refresh, so the cookie carries a short-lived result rather than a remembered sign-in, and the user is not prompted while the conditions hold. What the cookie is exposed to between refreshes is unchanged: it remains valid for the lifetime the site set. An Intent to Ship for was approved in February 2026, so the mechanism is on a path to deployment rather than a proposal. Whether a user agent can use a key gated on conditions outside its own control is an implementation question this document does not answer. is deliberately silent on how keys are stored, which leaves the question open rather than settled against.

WebAuthn Credentials A condition-bound key can be used as a full FIDO credential, or in a non-FIDO version, for broad enterprise use with no user interaction. This document does not propose changes to and does not specify either mode.

Continuous Access Evaluation Continuous access evaluation carries a decision from a transmitter to a receiver, and its architecture assumes those are different parties: the party that observes a change is not the party that enforces it. The endpoint has no defined role, so a fact the endpoint observes must first reach a transmitter before it can act. Where the endpoint both observes the condition and holds the key, it can enforce what it sees without anything being transmitted. This does not make continuous access evaluation unnecessary. It remains what it was always needed for: conditions decided somewhere other than where the key lives, such as an administrative revocation, a change of entitlement, or a risk signal from a service the endpoint cannot see. What it suggests is that the endpoint is an under-used party in these designs, and that giving it a defined role reduces how much has to travel.

What Each Party Can Verify A verifier accepting a condition-bound key establishes three things: that the key is one it has registered or can trace to an accepted trust root; that the peer in this exchange proved possession of that key; and that the key's use was gated by the policy the verifier intends to rely on, with evidence for that policy fresh enough for its purposes. Any of these failing means the use fails closed. Stated in that form, the checks assume a single verifier that is also the TLS peer: the party that checks possession is the party that decides. In OAuth this is generally not the case. The authorization server authenticates the client directly. The resource server receives a token issued by the authorization server, and may or may not hold a mutual-TLS connection to the client. The two therefore observe different things and can conclude different things, and a profile that does not distinguish them will overclaim at the resource server.

At the Authorization Server The authorization server is the TLS peer of the client. It observes a completed handshake in which the client signed with the binding key, and it holds, from registration or enrollment, evidence about that key's use policy. It can therefore establish:

that the client controls the registered key (from the handshake);
that the key was, at registration, gated on a stated use policy (from enrollment evidence, including Attestation Results in the sense of where available); and
consequently, that the gating conditions held at the moment of this request, to the assurance level of the enrollment evidence.

The third conclusion is the one that carries the profile, and its strength is bounded by the second. A verifier that has no evidence about the key's use policy learns only that a key was used. A profile MUST state what evidence establishes the key-use policy and what freshness rule applies to it, and an authorization server MUST NOT treat a successful client authentication as evidence of conditions when it holds no evidence of the policy gating the key.

At the Resource Server The resource server's position depends on how the token is constrained. With a certificate-bound access token and a mutual-TLS connection reaching the resource server, the resource server is a TLS peer and its position resembles the authorization server's: the completed handshake demonstrates that the key was usable for this request. Whether it can go further and conclude anything about conditions depends on whether it has evidence of the key-use policy, which it typically does not obtain directly. Where the authorization server holds that evidence, it MAY convey the result of its appraisal in the token; the resource server then relies on the authorization server's appraisal rather than on its own, and this MUST be represented as such. With DPoP, the resource server verifies a per-request signature. The same distinction applies: the signature demonstrates present usability of the key; any conclusion about what gates that key rests on evidence the resource server did not itself observe. With a bearer token, the resource server learns nothing from this profile. There is no proof to fail. Condition-binding makes the failure reliable everywhere a proof is required, and makes the appraisal available only where evidence of the key-use policy is held. A profile MUST NOT claim that a resource server verifies conditions when what it verifies is a signature whose production was gated by conditions it cannot observe.

Effect on Tokens Already Issued What happens to a token already issued, when a condition fails afterwards, depends on the token type. A bearer access token already in the client's possession is unaffected. It is a copyable artifact whose acceptance requires no proof, so there is no proof to withhold. It remains usable until it expires or is rejected by some other means. Deployments relying on bearer tokens SHOULD continue to use short access-token lifetimes; this profile does not remove that requirement and does not reduce the need for it. A sender-constrained access token -- certificate-bound per or DPoP-bound per -- is a different case. Its acceptance requires the client to demonstrate possession of the binding key at each use. If that key is condition-bound and a required condition fails, no new demonstration can be produced, and the token is unusable from that moment, subject to the DPoP pre-generation window in . This occurs without a revocation message, without the resource server learning why, and without any action by the user. It is not that the token is revoked; it is that the token can no longer be used. Refresh tokens follow the same rule, and in the ordinary deployment they follow the stronger side of it: where the client authenticates to the token endpoint with a condition-bound key, a refresh request on a new connection cannot complete once a condition fails, regardless of the refresh token's own constraint. This is subject to the connection-reuse and resumption limits in .

Delegated and Asynchronous Flows Delegated flows built on token exchange , in which one party acts for another and may continue after the user goes offline, are where the distance between a decision and its use is largest, and therefore where this profile is most consequential. In such a flow an acting party authenticates to the authorization server, presents a token addressed to it, and receives tokens with which to continue a task. Policy is re-evaluated by the authorization server at each such request. Between requests the authorization server observes nothing, and a token already issued remains usable for its lifetime. The usual mitigation is to shorten the interval and the lifetime. That reduces the exposure without removing it, and trades against the long-running task the flow exists to support. Where the acting party's client authentication key is condition-bound, the interval closes rather than shortens. The authorization server still re-evaluates its own policy at each request; in addition, no request can be made on a newly established connection unless the acting party's conditions hold at that moment. The two are complementary: the authorization server enforces what it can see, and the platform enforces what only it can see. Two limits MUST be stated by any profile applying this to a delegated flow. First, the conditions enforced are those of the platform where the key lives; where a task is delegated to a party on another platform, that party's conditions are what gate its key, and the original user's conditions are not thereby enforced. Second, autonomous operation across a period of user unavailability necessarily rests on a pre-authorization made while the user was present; condition-binding constrains where and under what platform state that authorization can be exercised, and does not remove its pre-authorized character.

Failure Behavior Two enforcement paths MUST be distinguished, and a profile MUST state which conditions it assigns to each. Conditions the platform evaluates locally -- presence of the verified human, measured platform state, posture, local policy predicates -- are enforced by the key's absence. The party that observes the failure is the party that withdraws the key, so no message has to travel. Enforcement takes effect at the next use of the key. Conditions originating elsewhere -- an authorization narrowed by an administrator, a role removed, a platform distrusted by a central authority -- cannot be observed by the platform and are not enforced by key absence. These require an out-of-band signal, for example a Continuous Access Evaluation Profile event , carried by a signalling framework such as , or they take effect at the authorization server's next policy evaluation. This profile does not remove that requirement.

Connection Reuse and Session Resumption Enforcement by key absence acts at the next operation requiring the key. Two transport behaviors mean that an operation which required the key once may not require it again. Connection reuse. An established connection does not re-exercise the binding key while it runs. This is a property of connection-oriented transport rather than of this profile: certificate expiry and revocation act at the next handshake for the same reason. Over HTTP/2 and HTTP/3 it is more than a default. Section 9.2.3 and Section 4.4 prohibit post-handshake authentication outright, so there is no conforming way for a server to require the binding key again on a connection it has already accepted. A profile cannot close this by specifying more carefully; it can only choose a mechanism whose proof rides in the message, or bound the connection. A profile permitting long-lived connections MUST NOT represent the proof given at connection setup as continuing evidence that conditions still hold, and SHOULD bound connection lifetime, drive teardown from an external signal, or both. Session resumption. Resumption re-establishes an authenticated connection without exercising the binding key. In TLS 1.3 a resumed handshake authenticates from a pre-shared key derived from the earlier handshake and sends neither Certificate nor CertificateVerify (, Section 2.2). Earlier versions of TLS behave comparably. A resumed connection is therefore not evidence that gating conditions hold, and whether the certificate from the original handshake remains available to the application -- and so whether the check required by Section 3 passes or fails -- is implementation-dependent. A profile using condition-bound keys MUST specify its treatment of session resumption, and MUST do one of the following.

Disable resumption for connections used for mutual-TLS client authentication and for connections carrying certificate-bound access tokens. The first of these is the connection to the authorization server, which carries no access token and is the case in which this profile's enforcement is otherwise strongest.
Require the binding key to be exercised on the resumed connection before it is relied upon. TLS 1.3 post-handshake authentication (, Section 4.7.2) runs Certificate and CertificateVerify and so does exercise the key. It is not available over HTTP/2 or HTTP/3, for the reasons given above, and this option is therefore confined to HTTP/1.1 and to non-HTTP uses of TLS.
Bound ticket lifetime to the shortest-lived condition the profile enforces. Where that condition is the presence of a human, which can fail in seconds, this option collapses into the first: a ticket lifetime short enough to be honest is short enough that resumption serves no purpose. It is a distinct option only for profiles whose fastest-failing condition is measured in minutes or longer.

A profile MUST NOT permit indefinite extension of an authenticated session through chained ticket reissuance.

The Verified Human Actor OAuth's principal subject is a human, and the case this profile treats as central is a human verified into a platform, whose continued presence is a condition on the binding key. In this arrangement the user does not hold a key; the platform does, and the platform's key is usable only while that user is verified as present at it. The user is not asked to act at the moment of use. There is no user interaction, no prompt, and no code, because what is established is not that the user can perform an action but that the user is present, which the platform can determine without asking. The credential presented to the authorization server is therefore evidence about the present rather than a record of a past authentication event. That a verified human is present at a platform is an association, and it is all that is established. It is not consent to a particular action, not authorization for a particular scope, and not accountability for a decision. Consent and authorization remain the business of the authorization server and of tokens. Accountability is evidence of a past decision and is legitimately an artifact. A profile MUST NOT represent the presence of a verified human as approval of anything. An agent acting for a human is the composition of two actors. Where the agent runs on the platform at which the human is verified, both conditions gate the same key and the question of on whose behalf the agent acts is answered locally, at the moment of action, without a propagated claim. Where the agent runs elsewhere, it is a separate actor on a separate platform with its own key and its own conditions, and the human's authority reaches it as a conveyed, scoped permission. A profile MUST state which topology it addresses. A key gated only on the platform's state cannot distinguish which of several actors co-located on that platform is making a request; where such distinction is required, the key MUST be specific to the actor rather than to the platform.

Consequence for Sessions This section is informative and states a consequence rather than a requirement. A session exists because authenticating a user costs the user something. Ask once, at sign-in, then hold the result. Lifetimes, idle timeouts, renewal, and revocation all follow from holding it. A condition-bound key costs the user nothing. The user is verified into the platform, and the key signs only while that holds, so every request carries a live proof that the verified user is present. There is nothing to hold. Login and session become one thing, happening at each use. The key does not say who the user is; that remains the authorization server's determination, and tokens still carry authorization. What ends is the need for a stored sign-in result to stand in for a user who is there.

Applicability This profile suits actors on stable, attestable platforms: user endpoints, virtual machines with a virtual TPM, persistent services, edge and operational-technology systems, and long-lived agents. It is not proposed for high-churn, ephemeral, hardware-less clients, where a per-operation hardware signature is a throughput ceiling and short-lived software-keyed credentials remain the appropriate tool. The boundary is set by operation rate and hardware availability. Deployments whose access tokens are bearer tokens obtain the benefit at the authorization server only, per .

Security Considerations This document adds to the considerations in , which apply unchanged; those below concern only what changes when the binding key is condition-bound. The gate is software-observed. The key's non-extractability is enforced by hardware. The evaluation of the conditions gating its use is performed by software on the platform, reading sensors and policy state. A profile MUST NOT represent condition evaluation as a cryptographic property. What is cryptographic is that a new signature cannot be produced when the gate does not open; what the gate reads is a software judgment, and its integrity rests on the platform's measured state. A compromised or emulated root is not self-detecting. This profile does not claim that a condition-bound key detects compromise or emulation of the hardware root protecting it. That failure is addressed by attestation re-appraisal and by the external signalling path, not by the key's own behavior. Clone and extraction signals. Non-extractability is an assumption about a boundary, and boundaries can fail: an extraction exploit, a side channel, or a cryptanalytic break would leave a working copy of the key elsewhere, where the protections this profile relies on do not apply. In each of those cases two instances exist and each advances its own count. A per-credential monotonic use counter detects this: two instances each advance their own, and the values diverge. establishes the pattern, carrying such a counter in authenticator data. TLS provides no equivalent carrier, so a profile relying on this signal for a key presented in a TLS handshake MUST specify how the value is conveyed, and MUST treat it as advisory: an anomalous value is raised for review rather than treated as a failure, and it MUST NOT gate key production or token issuance. In OAuth deployments the natural scope is the registration of the key with a given authorization server, and the value may be reported alongside the proof. Virtualized platforms. Where the protection boundary is a virtual TPM, snapshot and rollback of the virtual machine can restore a key together with a platform state that no longer reflects reality. A profile using a virtual root MUST specify instance binding and rollback protection. Absence is not distinguishable from failure. A resource server or authorization server observing a failed proof cannot tell whether a condition failed, the platform is offline, or an attacker is present. This is a deliberate property -- the failure carries no information about why -- and it means that condition failure produces no signal usable for monitoring. Deployments requiring visibility into why access ceased MUST obtain it from the platform through a separate reporting path, and MUST NOT infer it from the failure. Offline behavior. Because validity is the present usability of the key rather than a signed lifetime, a party can authenticate without a live connection to an issuing authority. Where a deployment makes an externally sourced status a required condition, loss of connectivity means that condition cannot be confirmed and the key fails closed. A profile MUST state whether external status is a required condition, since this determines whether disconnected operation is possible or prohibited.

Privacy Considerations A non-rotating key is a correlation handle. The properties this profile relies on come from a key that does not change: it is registered once, held in hardware, and presented for as long as the platform and the enrollment last. The same public key, or the same certificate thumbprint, is therefore presented to every resource server the client reaches over mutual TLS, and appears in the confirmation claim of every certificate-bound token issued for it. Two resource servers under different administrative control can determine that they are speaking to the same client instance by comparing that value alone, without cooperation from the authorization server. Rotation, whatever else it costs, breaks this. A deployment adopting this profile is trading unlinkability for the properties described in , and the trade should be made deliberately. For governed enterprise actors it is usually the right trade and supports accountability and audit. It is not the right trade everywhere, and this document does not claim it is. A profile SHOULD register a separate key per authorization server rather than one key across all of them, which confines correlation to the resource servers of a single trust domain. A profile MAY register a separate key per resource server where the deployment can bear the enrollment cost, which removes the handle at the cost of the operational simplicity that motivates a single key. A profile MUST state which it does. What presence detection observes, and what leaves the endpoint. A condition gating the key on the verified presence of a human is evaluated by observing that human -- by a sensor, a proximity measurement, a periodic re-verification, or a combination. These observations are made continuously and are of a person, and they are among the more sensitive things a platform can hold. The structure of this profile keeps them local. The gate is evaluated at the endpoint, and what reaches the authorization server or the resource server is a signature or its absence. No sensor reading, no posture measurement and no record of when presence lapsed travels as a consequence of the mechanism specified here. This is the same property describes as a limitation for monitoring -- the failure carries no information about why -- read from the other side: it is also a disclosure limit, and it holds by construction rather than by policy. It holds only for the gate itself. A deployment that separately reports presence state, posture, or the reason for a failure over a different path -- a management channel, a continuous-evaluation event, a telemetry stream -- discloses whatever that path carries, and requires such a path to exist wherever visibility is needed. A profile MUST state what its reporting path discloses, to whom, and at what granularity, and MUST NOT describe the mechanism in this document as privacy-preserving on the strength of the gate alone when such a path is in use. Enrollment evidence. The verifier's evidence about the key-use policy is established at enrollment, and it is the place where detail about the platform is disclosed. Attestation evidence can carry device identity, firmware and software versions, measured state, configuration, and the identity of the operator. A verifier needs enough of this to appraise the policy; it rarely needs all of it. A profile SHOULD convey an Attestation Result or a policy decision in the sense of rather than raw measurements, so that the appraisal happens once, at a party equipped for it, and the relying parties receive a conclusion. Where raw evidence is conveyed, a profile MUST state what it contains and SHOULD restrict it to the predicates the relying party appraises. Pre-authorization. A permission granted in advance to cover a period of user unavailability, as described in , is for its duration a conveyed artifact rather than a live condition, and is correspondingly more exposed to the properties this profile otherwise removes. It SHOULD be kept short and narrowly scoped.

Relationship to Existing Work This document builds on and and changes neither, and introduces no new party to any flow. The general credential and validity model, its terminology, and the verifier checks that this document extends to the two-verifier case are specified in . That document addresses workload identity within a trust domain; this one addresses the OAuth-facing case, where a human is the principal subject, tokens are issued by an authorization server, and the party deciding is often not the party that held the channel. Work on delegated and asynchronous authorization, including refresh token profiles for token exchange, specifies what an authorization server maintains and enforces across a delegated task. This profile is complementary to that work: it constrains what the acting party can do between the authorization server's evaluations, and leaves the authorization server's requirements intact. Work on client instance identity and on attestation-based client authentication addresses how an authorization server learns about a client instance it has not enrolled. This profile is orthogonal: it concerns the properties of the key once the client is known, whichever mechanism established that knowledge.

IANA Considerations This document has no IANA actions.

Acknowledgements The authors thank the participants of the OAuth and WIMSE working groups whose discussions of delegated authorization, agent identity, and proof-of-possession informed this work.