WinMagic

thi.nh@winmagic.com

WinMagic

sergei.nikitin@winmagic.com

WinMagic

John.OLeary@winmagic.com

Security mutual TLS user authentication condition-bound key Live Key session A user's access to an online service is secured today in two parts. A login establishes who is there and ends in a verdict, which a cookie or token carries to later requests. The session is then protected by other means, such as binding that token to a key. The login does not establish the key that protects the session, and that leaves a gap between the two. This document describes authenticating the user the way workloads are commonly authenticated: in the TLS handshake. The user signs in to their own device. The device holds a condition-bound key that can sign only while that user is using the device, the device is the enrolled one, and its state meets local policy. Used as the TLS client key, it makes the handshake the login and the TLS session the session. The key represents the identity (the user, the device and its state) at the moment of use, so identity assurance is carried in each transaction and nothing else has to stand for it: no separate login to the service and no session credential. When a condition fails, the key can no longer sign, and access ends at the next full handshake without a revocation message being sent. This is not an extension of OAuth. OAuth starts after the login; this removes the login to the service and the token that carries its result. Authorization is unchanged and can still come from OAuth. The document describes the properties of such a key, its use in mutual TLS, what a relying party can conclude from it, what parties would need to agree on for it to interoperate, and how it relates to existing mechanisms. Note to Readers Discussion of this document is requested on the DISPATCH mailing list (dispatch@ietf.org). The authors have been looking for the right place for this work since August 2025. In 2026 they brought it to two working groups. In WIMSE, from June (draft-winmagic-wimse-condition-bounded-credentials), the mechanism fits, and the charter states that the group will not define personal identities. In OAuth, from July (draft-winmagic-oauth-condition-bound-keys-00), users are in scope, and the authentication of the user is outside the framework. This document replaces the OAuth draft. It states the general case first and keeps the OAuth analysis in one section. Advice on where the work belongs would be welcome. A reference implementation of the key and its use in mutual TLS on Windows is public at https://github.com/WinMagic/LIT. No organization outside the authors' has told them it plans to deploy this. The document is deliberately not exhaustive. It does not attempt a threat model, a registration protocol or a worked attestation mechanism. Comment on the approach is more useful at this stage than detail on what is not covered.

Introduction

How a User Reaches a Service Today A workload in a service mesh usually authenticates in the connection. It holds a key, the mutual TLS handshake proves possession of the key, and the peer knows who is calling. The workload does not log in. No token is needed to say who it is; where a token is used, it says what the workload may do. A user reaches a service differently. A login establishes who is there, using a password, a one-time code, a push approval or a FIDO2 assertion, and its result is written into a cookie or a token that later requests present. Protecting that artifact is a second problem with its own mechanisms: short lifetimes; binding the token to a key held by the application, with mutual TLS , DPoP or HTTP Message Signatures ; device-bound browser sessions ; and continuous access evaluation . Two problems, two sets of solutions. The second problem exists because user authentication ends in a verdict, not a key. Each method above establishes that the right person is present at that moment. None of them, passkeys included, establishes a key that protects the exchange that follows, as an authenticated key exchange does. The connection that carries the exchange was secured before the login or apart from it, and what connects the user to that connection afterwards is the artifact: a record of the login. Where the artifact is bound to a key, what connects the two is an issuer's decision to name that key, not a derivation. This leaves a cryptographic gap between the login and the session. As far as the authors know, it is present in the sign-in methods most web services use today. It is not a weakness in the cryptography of any of these methods, each of which does what it was designed to do. It is in how they are composed with the connection: the step that proves the person and the handshake that produces the traffic keys are separate, and nothing joins them. The fix already exists in mutual TLS, where the handshake that proves who is connecting also produces the keys that protect what follows (). That join is where adversary-in-the-middle phishing works. Where a login can be relayed, the adversary relays a genuine one and is issued a session credential of its own, and every check on later requests passes. Binding the credential to a key does not prevent this, because the credential is bound to the adversary's key. What stands for the user on each request was made for something else: a token to carry authorization, a cookie to keep a session, a certificate to carry a certification authority's statement about a key. None of them was made to stand for the identity now. Every request after the login is checked, often rigorously: the artifact's signature, expiry and audience, and sometimes its binding to a key. What is checked is the artifact. Whether the person it was issued to is still there, and whether the device is still in an acceptable state, is not checked, because neither fact is in the request and the server cannot observe either. A token's expiry is an estimate of how long the facts checked at login will stay true. In client and server terms: the server decides to return data many times a second and cannot re-authenticate the user each time. It can check a key or a token. It cannot see whether the user is still at the device, or whether the device is still in a good state. The endpoint can.

Authenticating the User in the Handshake This document proposes authenticating a user the way a workload is authenticated: in the connection. The user signs in to their own device, with whatever factors local policy requires. The device then holds a key that can sign only while that user is using the device, the device is the authentic, enrolled one, and its security posture meets policy. When any of these stops being true, the key can no longer sign. This document calls it a condition-bound key. The endpoint uses the key as its TLS client key. The handshake is then the login: the relying party learns from it, on every connection, who is there. The TLS session is the session: the traffic that follows is protected by keys derived from the same handshake. Nothing is issued to stand for the login, so no session credential exists to be stolen, replayed or revoked. The key represents the identity, meaning the user, the device and its state, at the moment of use. Identity assurance is therefore carried in each transaction. No token is needed for identity, and so there is no separate login and no session credential. The endpoint decides. It checks the user and its own state, and uses the key only while every condition holds. Authentication, in the sense of identity now, is done by the endpoint, and the relying party benefits from it at every connection without any message having to reach it. Nothing changes in TLS, and the checks a relying party already makes stay the same. What changes is what a passing check means. Authorization is not part of this. What the user may do still comes from the relying party's own policy, an authorization server or a token. The key establishes that a verified user is currently at this endpoint under these conditions, and nothing more (). This is therefore not an extension of OAuth. OAuth begins after the user has been authenticated and leaves that authentication out of scope (); this document replaces that authentication and the token that carries its result. Nor is it a profile of workload credentials ().

What Exists and What Was Missing The standards needed are already in place. Mutual TLS has authenticated machines this way for decades. TLS has accepted raw public keys since 2014 . Registering a public key directly with a service is how SSH keys and passkeys are registered. The Host Identity Protocol made a public key the identity of a host, with the exchange that proves the identity also deriving the keys that protect the traffic. Users have been authenticated this way too, with smart cards. The US Department of Defense Common Access Card and US federal PIV cards authenticate users to networks and web services with a certificate in TLS client authentication, and some sites require the card on every connection. Identity providers accept a card in mutual TLS at sign-in, for example Microsoft Entra certificate-based authentication . Estonia's national identity card has logged people in to web services by TLS client certificate authentication since 2002. Services began moving to Web eID in 2023, and the Information System Authority has asked all e-services to complete the move by the end of 2026 ; its guidance has also recommended TLS client certificate authentication for services with strict security requirements . NIST SP 800-63B gives client-authenticated TLS as its example of channel binding, in which the client signs "along with earlier messages from the protocol that are unique to the particular TLS connection being negotiated" (, Section 3.2.5.1), and allows session secrets to be derived from the keys of a mutually authenticated protected channel (Section 5.1). SP 800-63C gives a holder-of-key example at FAL3 in which the subscriber authenticates to the relying party with a smart card . It stayed with cards, and with the populations that issue them. A card needs a reader, middleware and a PIN; certificate choices and prompts differ by browser and operating system; certificates have to be issued and renewed; and TLS is often terminated before the application. Estonia's reasons for Web eID include the reliability of browser and operating-system interfaces, logout behaviour with cached PINs, and the special TLS configuration servers needed in cloud and clustered deployments . A 2020 analysis for the Information System Authority noted that TLS client authentication can bind the whole session to the client's certificate if it is required after the login, at the cost of keeping the card's authentication context active after the first PIN entry, "which poses a security threat of its own" . In many deployments the card authenticates only at a sign-in to an identity provider, and the application session then runs on cookies and tokens, which brings the gap back. A card is also a presence gate of a kind. Once removed it cannot sign, and many sites lock the workstation when it is removed. What that shows is that the card is present, not that the person is, and it says nothing about the state of the machine. What was missing is a client-side key that can stand for a person and be used with no action from them. An endpoint can hold a key that stands for the user, the device and its state together, and present it with no user action.

Scope This document describes the condition-bound key (), its use as the TLS client key (), what a relying party can conclude from it (), what changes for logins, sessions, tokens and revocation (), what parties would need to agree on for it to interoperate (), and its relationship to existing mechanisms (). Applicability, security and privacy follow. It changes no protocol and defines no new protocol element. It does not define a policy language, an attestation format, a registration protocol or a hardware recipe.

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

Actor

The entity a key stands for: a person verified into a device, a workload, or an agent acting for a person.

Endpoint

The device on which the actor acts, including its hardware, firmware and execution environment. The endpoint creates, protects and uses the key. In this document it is the TLS client.

Condition

A predicate, evaluated at the endpoint, that must hold for the key to be usable: for example, that the verified user is using the device, that the device is the enrolled one, and that its measured state and posture meet policy.

Condition-Bound Key

A private key that cannot be extracted from the endpoint in usable form and that can produce a signature only while every required condition holds (). Its validity is its present usability, not a date carried in a credential.

Identity

As used here, the combination of an actor, an endpoint and the conditions under which the actor is acting. A condition-bound key represents an identity in this sense, and only while all three hold.

Relying Party

The party that accepts the TLS connection and decides whether to give access: a service, an identity provider, an authorization server or a resource server.

TLS Client

The party that initiates the TLS handshake. Where this document means the OAuth client role, it says "OAuth client".

Registration

The one-time act in which a relying party records the public key of an actor's key on an endpoint and associates it with an account. It is not a login and is not repeated per session.

Condition-Bound Keys

Properties A key is condition-bound when all of the following hold:

1. The private key is generated and used inside a boundary from which it cannot be extracted in usable form, and signing happens inside that boundary.
2. Use of the key is gated by policy evaluated at the endpoint, so that the key cannot produce a signature while any required condition is unsatisfied.
3. The gate is enforced, not asserted: if a copy of the key can exist and be used outside the boundary, the property does not hold.
4. Evidence is available to a relying party that the key's use is gated by the policy it intends to rely on.

Properties 1 to 3 are properties of the endpoint. Property 4 is what lets a relying party know it is dealing with such a key, because a signature from a condition-bound key looks the same on the wire as a signature from any other key (). Every required condition must hold for the key to sign, and any one failing is enough to stop it. Whether the endpoint erases the key when a condition fails, or keeps it unusable behind policy, is an implementation choice. To a relying party the two are the same: no signature can be produced.

Validity Presence is validity: validity is the present usability of the key, so nothing declares it in advance and nothing has to withdraw it afterwards. A relying party that obtains a signature from the key in a handshake, and holds the evidence of property 4, has evidence that the conditions held when the signature was made. A key pair always works mathematically. What stops is the endpoint's willingness to use it: the boundary that holds the key refuses to sign once a condition fails, in the way a key sealed to a platform or enclave measurement cannot be used when the measurement changes. The public key, and a relying party's trust in it, do not have to change, because no signature is produced to be trusted.

Conditions and Who Observes Them Conditions the endpoint evaluates itself are enforced by the key's inability to sign: that the verified user is using the device, the device's measured state, its posture, and local policy predicates. The party that observes the failure is the party that withdraws the key, so no message has to travel. The user logging out of the device and the device falling out of policy are the usual examples. Conditions decided elsewhere cannot be observed by the endpoint and are not enforced by the key: an account suspended, a role removed, a device distrusted by a central authority. They are enforced by the relying party's own policy, or delivered as a signal to the party that must act, for example a Continuous Access Evaluation Profile event carried by the Shared Signals Framework . Each decision is made where its facts can be observed.

Per Actor and Per Endpoint The key is created per actor and per endpoint. The same person on two devices has two keys; two actors on one device have two keys. A key gated only on the device's state cannot tell apart several actors on that device. Where that distinction matters, the key MUST be specific to the actor.

Hardware and Software A key held in hardware keeps property 1 for its whole life. A key held in software keeps it only until it can be read out and copied. This document does not require hardware. A relying party learns which kind of key it is dealing with from the evidence of property 4 and decides whether to rely on it.

Use as the TLS Client Key

The Handshake Is the Login The endpoint, as TLS client, presents the public key of its condition-bound key in the handshake, as a raw public key or inside a self-signed certificate, and signs the handshake transcript with it in the CertificateVerify message (). The relying party matches the presented key against the key registered for that actor and endpoint. A match with a valid signature is the authentication. Because the signature covers the transcript, which includes both parties' key-exchange values, proving who is there and establishing the traffic keys are one operation. A signature made in one handshake is of no use in another. An adversary in the middle that terminates the endpoint's connection cannot use the endpoint's signature to authenticate to the relying party, and one that passes the handshake through unchanged does not obtain the traffic keys.

The TLS Session Is the Session Traffic after the handshake is protected by symmetric keys derived from it. They are never sent and work only on this connection. The relying party does not need to issue a cookie or a token to recognize the user on later requests on the connection. On a new connection, the handshake proves it again. Applications can keep per-user state as they do today. What they no longer need is a credential that stands for the authentication.

Registration in Place of Certificates A certificate lets a relying party accept a key it never registered, on the word of a third party. That is what strangers need. A service and the endpoints enrolled to use it are not strangers, and a certificate's authority, chain, expiry, revocation lists and renewal add work without adding assurance. The relying party registers the public key once () and matches it at each handshake. Where software requires a certificate, a self-signed certificate wrapping the same key serves; its dates and issuer carry no meaning.

Connection Lifetime and Resumption As in every use of TLS, the private key authenticates the handshake, and the traffic that follows is protected by keys derived from it. A condition that fails while a connection is open takes effect at the next handshake. How long an authenticated connection may live is a setting the relying party chooses, as it chooses a session timeout today. Over HTTP/2 and HTTP/3 a new connection is how the key is exercised again, because both prohibit post-handshake client authentication (; ). Unlike a cookie or a bearer token, a TLS session key cannot be presented on another connection. A resumed TLS 1.3 handshake authenticates with a pre-shared key from the earlier connection and carries no Certificate or CertificateVerify message (). It does not exercise the condition-bound key and is not a new authentication. A relying party using this mechanism SHOULD disable resumption on these connections or limit resumption tickets to the connection lifetime it has chosen, and MUST NOT allow an authenticated connection to be extended indefinitely by chained ticket reissuance.

TLS-Terminating Intermediaries The property reaches as far as the TLS connection does. Where a CDN, load balancer or gateway terminates TLS in front of the relying party, the intermediary is the TLS peer and performs the verification. It can forward the TLS client's certificate to the origin , and the origin then relies on the intermediary's verification. Where the proof has to reach a party beyond the terminator, a proof carried in the HTTP message can use the same key ().

Applications Any application that opens a TLS connection can present the key: a native application, a browser, a remote-desktop client or an agent. A browser presents a TLS client key through the platform's key store and its own certificate selection. Whether it can do so without user interaction, and only to relying parties for which the key is registered, depends on the platform and is outside this document.

What a Relying Party Can Conclude A relying party that completes the handshake establishes that:

1. the key presented is the one registered for this actor and endpoint;
2. the endpoint proved possession of it in this handshake; and
3. if the relying party holds evidence of the key's use policy (), the conditions in that policy held when the signature was made, to the assurance that the evidence supports.

Without the evidence in item 3, the relying party learns only that a registered key was used, and MUST NOT treat the handshake as evidence about conditions. What is established is association: a verified user is currently at this endpoint, under these conditions. It is not consent to an action, not authorization for a scope, and not accountability for a decision. A relying party MUST NOT treat the presence of a verified user as approval of anything. Who the user is, beyond what registration recorded, and what the user may do still come from the relying party's own records, an identity provider or an authorization server. Only the TLS peer observes the handshake. A party behind it, such as an origin behind a TLS-terminating intermediary or a resource server that is not itself the TLS peer, learns what the TLS peer tells it and relies on the TLS peer's verification. Such a party MUST NOT be described as verifying conditions. A relying party that sees a handshake fail cannot tell whether a condition failed, the endpoint is offline, or someone without the key tried to connect. The failure carries no reason ().

What Changes

No Separate Login The user signs in once, to their own device. After that the device authenticates the user to each relying party at each connection, with no prompt, no code and no approval. For a relying party reached this way there is no login page for an attacker to imitate and no verdict to relay ().

No Session Credential Nothing is issued to carry the login forward. There is no session cookie or token for authentication, so nothing exists to be copied, replayed, bound, refreshed or revoked for that purpose. Mechanisms that bind a session credential to a key protect that credential (); here, for identity, there is no credential to protect.

Tokens Carry Authorization Where tokens are still used, they carry what the user may do. Their lifetime no longer has to bound how long the record of a past authentication can be used, because authentication happens at each connection. Lifetimes need not change. They are no longer what ends access.

Access Ends Where the Facts Are Observed When the user logs out of the device, or the device falls out of policy, the endpoint can no longer sign. The next full handshake with every relying party fails, and nothing is sent to any of them. Conditions decided elsewhere are handled by the relying party's own policy or by a signal (). The decision about whether the user is still there is made at the endpoint, which can observe it.

What Parties Need to Agree On A condition-bound key is a property of the endpoint. An endpoint can create one without any other party's agreement, and on the wire its signatures look like those of any other key. For the arrangement to interoperate, parties need to agree on four things. None of them changes TLS.

Registration The first is registration: how a relying party records the public key for an actor on an endpoint, associates it with an account, and replaces it when the endpoint is replaced or re-enrolled. A relying party can register keys directly, as it registers WebAuthn credentials or SSH keys, or rely on an identity provider that names the key for it in an assertion or token, as the confirmation claim allows. Either way, what the relying party learns is which key belongs to which account; the authentication happens in its own handshake. An identity provider in this arrangement is present before and around the connection, and not inside it.

The Key's Use Policy and Its Evidence The second is how a relying party learns which conditions gate the key, and what class of evidence supports each: enforced in hardware or in software, attested at registration or attested again later. Without this, a relying party cannot tell a condition-bound key from any other key and cannot decide whether to rely on it. Attestation Results in the sense of are one carrier, and registration is the natural time to convey them. Of the four, this is the one most likely to need new specification.

Past a TLS Terminator The third arises where an intermediary forwards the TLS client's certificate to the origin . The origin needs to learn that the key is condition-bound and that the intermediary verified the handshake, not only which key was used.

Signals The fourth is signals, for conditions one party observes and another needs: a relying party or identity provider telling the endpoint that an account or role has changed, and an endpoint telling a relying party that presence or posture has changed, where the relying party wants to know before the next handshake. The Shared Signals Framework is the natural carrier. A per-registration use counter, which reveals a cloned key when two instances advance it independently (), would also need a carrier. TLS has none.

Relationship to Existing Mechanisms

OAuth OAuth leaves the authentication of the user out of scope: "The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification" (). This document does not add authentication to OAuth. Where it applies, a token no longer has to stand in for an authentication and can carry authorization alone. This section carries forward the analysis of . Mutual-TLS client authentication authenticates an OAuth client in the TLS handshake. In its main deployments, such as financial-grade APIs, the TLS client is a confidential client, which is a server-side application, and not the user's endpoint. A condition-bound key can be the key of an OAuth client running on the endpoint, under the self-signed method (self_signed_tls_client_auth), which matches registered keys and validates no chain. A certificate-bound access token is then usable only on a connection the key authenticated. The resource server's thumbprint check does not change; a passing check now also implies that the key's conditions held at that handshake, to the extent the evidence of supports. DPoP and HTTP Message Signatures carry the proof in the HTTP message. The same key can be the proof key under either, unmodified. The proof then survives a TLS-terminating intermediary and is produced per request. A DPoP proof generated while the conditions held can be presented after they fail, within the acceptance window the server applies (); server-provided nonces (Sections and of ) shorten that window. In JOSE structures the key is represented as a JSON Web Key , like any other key. The raw public key form of is used only in the TLS handshake. A bearer token already issued is not affected and remains usable until it expires. A sender-constrained token becomes unusable when the key can no longer sign, without a revocation message, subject to the DPoP window above. Where the OAuth client authenticates to the token endpoint with the key, refresh and token exchange requests on a new connection fail the same way.

OpenID Connect, FIDO2 and WebAuthn FIDO2 and WebAuthn authenticate the user at a login, and OpenID Connect carries the result of a login from an identity provider to a relying party. Each ends in a verdict that a session then carries. A condition-bound key can serve as a WebAuthn credential, with the user interaction WebAuthn requires, or outside FIDO with none. This document proposes no change to WebAuthn and does not specify either use. What the key adds is that the same key can authenticate the connection, so the verdict does not have to be carried.

Token Binding Token Binding let a TLS client hold a long-lived key per server, prove possession of it on each TLS connection, and have cookies and tokens bound to that key, including tokens an identity provider issued for use at a relying party. It was published as a Proposed Standard in October 2018, and Chrome removed its implementation the same year. In Token Binding the token still carried the identity, and the binding protected the token. In the arrangement described here no token carries the identity, so for identity there is nothing to bind. The same holds for the binding mechanisms in and , which keep their place where TLS is terminated before the service and for tokens that carry authorization.

Device Bound Session Credentials Device Bound Session Credentials bind a browser session to a key the browser creates when the site registers a session, typically after the user signs in, and refresh short-lived cookies by proving possession of it. DBSC is generally available in Chrome on Windows . The key is bound to the device, not to the user's continued use of it. If the DBSC key were condition-bound, a failed condition would stop the next refresh, and outstanding cookies would expire within the lifetime the site chose. In the arrangement described here, no session cookie is issued at all. Whether a user agent can use a key gated on conditions outside its control is an implementation question; DBSC leaves key storage to the implementation.

Shared Signals and Continuous Access Evaluation Continuous access evaluation carries a change from a transmitter to a receiver over the Shared Signals Framework . In typical deployments the transmitter is a service, such as an identity provider or a device-management system, so a fact the endpoint observes reaches a relying party only after it reaches such a transmitter. Where the endpoint both observes a condition and holds the key, it enforces what it observes with nothing transmitted. Signals remain necessary for conditions decided elsewhere () and are the carrier for anything the endpoint reports ().

Workload Identity Workloads already authenticate in the connection (), and the WIMSE working group is standardizing workload credentials and their use with mutual TLS. Its charter states that it will not define personal identities. applies the condition-bound property to workload credentials within a trust domain. This document addresses the person verified into a device.

Agents and Delegation An agent acting for a person is two actors. Where the agent runs on the person's endpoint, its key can be gated on the person's conditions as well as its own, so on whose behalf it acts is answered at the endpoint at the moment of action. Where the agent runs elsewhere, it uses its own key on its own platform, gated on its own conditions, and the person's authority reaches it as a grant made while the person was present, as in delegated flows built on token exchange . The person's conditions are not enforced on the agent's platform; condition-binding constrains where, and under what platform state, the grant can be exercised. In a chain of agents, each hop can prove its own actor, platform and conditions in its own handshake, so no hop depends on a credential carried from an earlier one. This document does not solve propagation: when a condition fails for an actor early in a chain, later actors learn of it only through a message.

Cross-Device Flows BCP 247 states that "Cross-Device Consent Phishing (CDCP) attacks exploit the unauthenticated channel between the Consumption Device and Authorization Device using social engineering techniques" (Section ), and that "Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated" (Section ). A cross-device flow exists because the device consuming the service cannot authenticate the user itself. An enrolled endpoint holding a condition-bound key can, so for such endpoints the flow is not needed.

Zero Trust Architecture NIST SP 800-207 states: "Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established." This document keeps subject and device together and moves their authentication from before the session into every connection.

Applicability The mechanism suits actors on platforms that can be enrolled and can hold a key: managed user devices, virtual machines with a virtual TPM, persistent services, edge and operational-technology systems, and long-lived agents. Because validity does not depend on reaching an issuer, it works disconnected or intermittently connected, unless a deployment makes an externally sourced status a required condition (). It is not proposed for high-churn, ephemeral TLS clients without a protected key store, where a signature per connection limits throughput and short-lived software credentials remain the appropriate tool. Unmanaged and personal devices need the platform, meaning the operating system or the browser, to offer condition-bound keys. This document does not assume that this is available today.

Security Considerations The gate is software-observed. Non-extractability can be enforced by hardware. The evaluation of conditions is performed by software on the endpoint, reading sensors and policy state. A deployment MUST NOT describe condition evaluation as a cryptographic property. What is cryptographic is that no signature can be produced when the gate does not open; what the gate reads is a software judgement whose integrity rests on the endpoint's measured state. Conditions that are measurements, such as a boot measurement or the identity of the enrolled device, produce fewer false failures than conditions that require judgement. Code running on the endpoint. An attacker running code on an endpoint that still meets policy can cause the key to sign while the conditions hold. The key confines that to the endpoint and to the time the conditions hold. It does not detect the compromise. Compromised or emulated roots. A condition-bound key does not detect the compromise or emulation of the hardware root that protects it. That failure is addressed by re-appraisal of attestation and by the signalling path, not by the key's 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. A per-registration monotonic use counter detects this once both copies are used, because each copy advances its own count and the values diverge. WebAuthn carries such a counter in authenticator data ; TLS has no carrier for it (). The signal is advisory: an anomalous value is raised for review and does not gate use of the key. Virtualized platforms. Where the protection boundary is a virtual TPM, a snapshot or rollback of the virtual machine can restore a key together with a platform state that no longer reflects reality. A deployment using a virtual root MUST provide instance binding and rollback protection. Connection lifetime and resumption. These are settings, discussed in . Absence and failure look the same. A relying party that sees a handshake fail cannot tell whether a condition failed, the endpoint is offline, or someone without the key tried to connect. The failure carries no reason, which also limits what it discloses (). A deployment that needs to know why access ceased obtains it from the endpoint through a separate reporting path. Offline operation. Because validity is the present usability of the key and not a signed lifetime, an endpoint can authenticate without a live connection to an issuer. Where a deployment makes an externally sourced status a required condition, loss of connectivity means the condition cannot be confirmed and the key fails closed. A deployment MUST state whether external status is a required condition, since this decides whether disconnected operation is possible. Registration and recovery. Registration is where a key becomes trusted for an account, so it is where an attacker would try to register a key of their own. Replacing a lost or broken device means a new key and a new registration, and the process that authorizes it needs the protection of any account-recovery process. This document does not specify it. Other ways in. The protection applies to access through the condition-bound key. Where an account can also be reached by another method, that method keeps its own weaknesses, and an attacker can use it instead.

Privacy Considerations A long-lived key is a correlation handle. A key registered with several relying parties is presented to each of them, and relying parties under different administration can tell that they are talking to the same endpoint by comparing it. A deployment SHOULD register a separate key per relying party, or at least per trust domain, and MUST state which it does. Per-actor keys () already separate the users of one device. What presence detection observes stays on the endpoint. A condition on the presence of the verified user is evaluated by observing that user, through sensors, proximity or periodic re-verification. These observations are made continuously, are of a person, and are among the more sensitive things an endpoint holds. The mechanism keeps them local: what reaches a relying party is a signature or its absence. No sensor reading, posture measurement or record of when presence lapsed travels as a consequence of the mechanism. Reporting paths disclose what they carry. A deployment that reports presence, posture or the reason for a failure over another path, such as a management channel, a Shared Signals event or a telemetry stream, discloses what that path carries. A deployment MUST state what its reporting path discloses, to whom and at what granularity, and MUST NOT describe the mechanism as privacy-preserving on the strength of the gate alone when such a path is in use. Registration evidence. Evidence about the key's use policy is conveyed at registration, and attestation evidence can carry device identity, firmware and software versions, measured state and configuration. A relying party needs enough of it to appraise the policy and rarely needs all of it. A deployment SHOULD convey an Attestation Result or policy decision in the sense of in place of raw evidence. Pre-authorization. A grant made in advance to cover a period when the user is absent () is, for its duration, a conveyed artifact and not a live condition. It SHOULD be short and narrowly scoped.

IANA Considerations This document has no IANA actions.

References Normative References Informative References National Institute of Standards and Technology National Institute of Standards and Technology Microsoft Web eID project Information System Authority (RIA) id.ee Information System Authority (RIA) id.ee Information System Authority (RIA) id.ee Cybernetica AS Version 1.3, prepared for the Information System Authority OpenID Foundation OpenID Foundation W3C Web Application Security Working Group W3C First Public Working Draft Google Google Workspace Updates W3C W3C Recommendation

Acknowledgements This document replaces draft-winmagic-oauth-condition-bound-keys-00, which Larry Zhu asked for as a write-up of the delegated case. The authors thank him, and the participants of the OAuth and WIMSE working groups whose reviews and questions on the earlier drafts shaped this one.