---
title: "Mutual TLS (RFC 8705): definition | KYA glossary"
url: https://knowyouragent.ch/en/knowledge/glossary/mutual-tls
lang: en
updated: 2026-10-12
license: © Innopulse Consulting GmbH
---

# Mutual TLS (RFC 8705)

Mutual TLS (mTLS) is a TLS connection in which the client also identifies itself with a certificate; RFC 8705 uses this to authenticate OAuth clients and bind tokens to their certificate.

With ordinary TLS, only the server identifies itself. With mutual TLS, the client also presents a certificate and proves possession of the related private key. RFC 8705, published in February 2020, defines two uses for OAuth: authenticating the client to the authorization server and certificate-bound access tokens that can only be used over a connection with the same certificate.

Mutual TLS is common in finance, for example in open banking. For agents working between companies, it is a strong binding to an organization, but it requires careful certificate management.

## Example

A company's purchasing agent accesses a wholesaler's interface. The connection uses mutual TLS with a certificate of the company, and the access token is bound to this certificate. An intercepted token is useless without the certificate and its key.

## How it differs

Mutual TLS binds at the connection level, DPoP at the application level. A certificate shows which organization a client belongs to, but not which action is allowed; that requires a mandate.

## In practice

- Use mutual TLS for agents between companies when both sides run certificate management.
- Bind access tokens to the certificate so they only work over the matching connection.
- Plan certificate expiry and rotation so agents do not lose access unexpectedly.

## Role in KYA

KYA does not verify TLS connections. KYA uses the same idea of a trusted anchor: keys and certificates count as proven only if their path ends at an anchor the [verifying party](https://knowyouragent.ch/en/knowledge/glossary/verifying-party) has provided itself.

Related check: [Agent and principal](https://knowyouragent.ch/en/method/checks) (`subject_agent_binding`). Do all parts name the same agent, is the [principal](https://knowyouragent.ch/en/knowledge/glossary/principal) named, does the agent hold the bound key?

[Verify now: open a matching example](https://knowyouragent.ch/en/verify?beispiel=paket)

## Frequently asked questions

### What is the difference between TLS and mutual TLS?

With TLS, only the server identifies itself with a certificate. With mutual TLS, the client also presents a certificate, so both sides identify themselves to each other.

### What are certificate-bound tokens?

Access tokens that contain the fingerprint of the client certificate. The server accepts them only over a connection in which the client presents exactly this certificate.

### When is DPoP the better choice?

When intermediaries such as load balancers that terminate TLS sit between client and server, or when no client certificate management is wanted.

### Does mutual TLS prove an agent's authority?

No. It proves which organization is behind a connection. Which action is allowed is shown only by a mandate with limits.

## Sources

- [RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://www.rfc-editor.org/rfc/rfc8705)

## Related terms

- [DPoP (RFC 9449)](https://knowyouragent.ch/en/knowledge/glossary/dpop)
- [Trust anchor](https://knowyouragent.ch/en/knowledge/glossary/trust-anchor)
- [Agent passport](https://knowyouragent.ch/en/knowledge/glossary/agent-passport)
- [OAuth 2.1](https://knowyouragent.ch/en/knowledge/glossary/oauth-2-1)

---
Quelle: https://knowyouragent.ch/en/knowledge/glossary/mutual-tls · KYA – Know Your Agent