User Authentication in the TLS Handshake with Condition-Bound Keys

1.1. 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 [RFC8705], DPoP [RFC9449] or HTTP Message Signatures [RFC9421]; device-bound browser sessions [DBSC]; and continuous access evaluation [CAEP]. 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 (Section 1.3).¶

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

1.2. 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 (Section 6).¶

This is therefore not an extension of OAuth. OAuth begins after the user has been authenticated and leaves that authentication out of scope (Section 9.1); this document replaces that authentication and the token that carries its result. Nor is it a profile of workload credentials (Section 9.6).¶

1.3. 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 [RFC7250]. Registering a public key directly with a service is how SSH keys and passkeys are registered. The Host Identity Protocol [RFC9063] 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 [ENTRA-CBA]. 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 [ID-EE-2026]; its guidance has also recommended TLS client certificate authentication for services with strict security requirements [ID-EE-AUTH]. 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" ([NIST.SP.800-63B-4], 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 [NIST.SP.800-63C-4].¶

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 [WEB-EID] [ID-EE-WEBEID]. 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" [OPEN-EID]. 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.¶

1.4. Scope

This document describes the condition-bound key (Section 4), its use as the TLS client key (Section 5), what a relying party can conclude from it (Section 6), what changes for logins, sessions, tokens and revocation (Section 7), what parties would need to agree on for it to interoperate (Section 8), and its relationship to existing mechanisms (Section 9). 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.¶

4.1. 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 (Section 8.2).¶

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

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

4.3. 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 [CAEP] carried by the Shared Signals Framework [SSF]. Each decision is made where its facts can be observed.¶

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

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

5.1. 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 [RFC7250] or inside a self-signed certificate, and signs the handshake transcript with it in the CertificateVerify message (Section 4.5.2 of [RFC9846]). 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.¶

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

5.3. 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 (Section 8.1) 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.¶

5.4. 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 (Section 9.2.3 of [RFC9113]; Section 4.4 of [RFC9001]). 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 (Section 2.2 of [RFC9846]). 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.¶

5.5. 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 [RFC9440], 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 (Section 9.1).¶

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

7.1. 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 (Section 5.1).¶

7.2. 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 (Section 9.3); here, for identity, there is no credential to protect.¶

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

7.4. 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 (Section 4.3). The decision about whether the user is still there is made at the endpoint, which can observe it.¶

8.1. 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 [RFC7800] 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.¶

8.2. 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 [RFC9334] 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.¶

8.3. Past a TLS Terminator

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

8.4. 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 [SSF] is the natural carrier.¶

A per-registration use counter, which reveals a cloned key when two instances advance it independently (Section 11), would also need a carrier. TLS has none.¶

9.1. 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" (Section 3.1 of [RFC6749]). 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 [I-D.winmagic-oauth-condition-bound-keys].¶

Mutual-TLS client authentication [RFC8705] 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 Section 8.2 supports.¶

DPoP [RFC9449] and HTTP Message Signatures [RFC9421] 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 (Section 11.2 of [RFC9449]); server-provided nonces (Sections 8 and 9 of [RFC9449]) shorten that window. In JOSE structures the key is represented as a JSON Web Key [RFC7517], like any other key. The raw public key form of [RFC7250] 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.¶

9.2. OpenID Connect, FIDO2 and WebAuthn

FIDO2 and WebAuthn [WebAuthn] authenticate the user at a login, and OpenID Connect [OpenID.Core] 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.¶

9.3. Token Binding

Token Binding [RFC8471] [RFC8473] 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 Section 9.1 and Section 9.4, which keep their place where TLS is terminated before the service and for tokens that carry authorization.¶

9.4. Device Bound Session Credentials

Device Bound Session Credentials [DBSC] 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 [CHROME-DBSC]. 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.¶

9.5. Shared Signals and Continuous Access Evaluation

Continuous access evaluation [CAEP] carries a change from a transmitter to a receiver over the Shared Signals Framework [SSF]. 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 (Section 4.3) and are the carrier for anything the endpoint reports (Section 8.4).¶

9.6. Workload Identity

Workloads already authenticate in the connection (Section 1.1), 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. [I-D.winmagic-wimse-condition-bounded-credentials] applies the condition-bound property to workload credentials within a trust domain. This document addresses the person verified into a device.¶

9.7. 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 [RFC8693]. 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.¶

9.8. Cross-Device Flows

BCP 247 [RFC10027] states that "Cross-Device Consent Phishing (CDCP) attacks exploit the unauthenticated channel between the Consumption Device and Authorization Device using social engineering techniques" (Section 1.1.3), and that "Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated" (Section 2). 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.¶

9.9. Zero Trust Architecture

NIST SP 800-207 [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.¶

14.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7250]

Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/info/rfc9846>.

14.2. Informative References

[CAEP]

Cappalli, T. and A. Tulshibagwale, "OpenID Continuous Access Evaluation Profile 1.0", OpenID Foundation, 29 August 2025, <https://openid.net/specs/openid-caep-1_0-final.html>.

[CHROME-DBSC]

Google, "Prevent account takeovers with Device Bound Session Credentials (DBSC), now generally available in the Chrome browser for Windows", Google Workspace Updates, 28 May 2026, <https://workspaceupdates.googleblog.com/2026/05/prevent-account-takeovers-with-DBSC-now-generally-available-in-the-Chrome-browser-for-Windows.html>.

[DBSC]

W3C Web Application Security Working Group, "Device Bound Session Credentials", W3C First Public Working Draft, 21 August 2025, <https://www.w3.org/TR/dbsc/>.

[ENTRA-CBA]

Microsoft, "Overview of Microsoft Entra certificate-based authentication", <https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication>.

[I-D.winmagic-oauth-condition-bound-keys]

Nguyen-Huu, T., Nikitin, S., and J. O'Leary, "Condition-Bound Keys for Mutual-TLS Client Authentication and DPoP", Work in Progress, Internet-Draft, draft-winmagic-oauth-condition-bound-keys-00, 11 August 2026, <https://datatracker.ietf.org/doc/draft-winmagic-oauth-condition-bound-keys/>.

[I-D.winmagic-wimse-condition-bounded-credentials]

Nguyen-Huu, T., Nikitin, S., and J. O'Leary, "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence", Work in Progress, Internet-Draft, draft-winmagic-wimse-condition-bounded-credentials-01, 6 July 2026, <https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/>.

[ID-EE-2026]

Information System Authority (RIA), "E-services must switch to the Web eID solution by the end of 2026", id.ee, 22 May 2026, <https://www.id.ee/en/article/e-services-must-switch-to-the-web-eid-solution-by-the-end-of-2026/>.

[ID-EE-AUTH]

Information System Authority (RIA), "Personal identification with an ID-card", id.ee, 29 December 2023, <https://www.id.ee/en/article/personal-identification-with-an-id-card/>.

[ID-EE-WEBEID]

Information System Authority (RIA), "Web eID", id.ee, <https://www.id.ee/en/article/web-eid/>.

[NIST.SP.800-63B-4]

National Institute of Standards and Technology, "Digital Identity Guidelines: Authentication and Authenticator Management", NIST Special Publication 800-63B-4, DOI 10.6028/NIST.SP.800-63B-4, 2025, <https://doi.org/10.6028/NIST.SP.800-63B-4>.

[NIST.SP.800-63C-4]

National Institute of Standards and Technology, "Digital Identity Guidelines: Federation and Assertions", NIST Special Publication 800-63C-4, DOI 10.6028/NIST.SP.800-63C-4, 2025, <https://doi.org/10.6028/NIST.SP.800-63C-4>.

[NIST.SP.800-207]

Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST Special Publication 800-207, DOI 10.6028/NIST.SP.800-207, August 2020, <https://doi.org/10.6028/NIST.SP.800-207>.

[OPEN-EID]

Cybernetica AS, "Analysis of planned architectural changes in Open-eID", Version 1.3, prepared for the Information System Authority, 18 December 2020, <https://web-eid.github.io/web-eid-cybernetica-analysis/webextensions-main.pdf>.

[OpenID.Core]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", 15 December 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/info/rfc7800>.

[RFC8471]

Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, "The Token Binding Protocol Version 1.0", RFC 8471, DOI 10.17487/RFC8471, October 2018, <https://www.rfc-editor.org/info/rfc8471>.

[RFC8473]

Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and J. Hodges, "Token Binding over HTTP", RFC 8473, DOI 10.17487/RFC8473, October 2018, <https://www.rfc-editor.org/info/rfc8473>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/info/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/info/rfc8705>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9063]

Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, <https://www.rfc-editor.org/info/rfc9063>.

[RFC9113]

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/info/rfc9334>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/info/rfc9421>.

[RFC9440]

Campbell, B. and M. Bishop, "Client-Cert HTTP Header Field", RFC 9440, DOI 10.17487/RFC9440, July 2023, <https://www.rfc-editor.org/info/rfc9440>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/info/rfc9449>.

[RFC10027]

Kasselman, P., Fett, D., and F. Skokan, "Best Current Practice for Security of Cross-Device Flows", BCP 247, RFC 10027, DOI 10.17487/RFC10027, August 2026, <https://www.rfc-editor.org/info/rfc10027>.

[SSF]

OpenID Foundation, "OpenID Shared Signals Framework Specification 1.0", 29 August 2025, <https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html>.

[WEB-EID]

Web eID project, "Web eID: electronic identity cards on the Web", <https://github.com/web-eid/web-eid-system-architecture-doc>.

[WebAuthn]

W3C, "Web Authentication: An API for accessing Public Key Credentials - Level 3", W3C Recommendation, 25 August 2026, <https://www.w3.org/TR/webauthn-3/>.