Visual RFC.
ALL RFCs / RFC 8705
Read the RFC ↗
RFC 8705 / CERTIFICATES AND PERMISSION

Show a card, then prove you own its key

01

A photo app wants permission to fetch pictures. A public certificate can be copied; the secret private key must stay with its owner.

RFC 8705 · § 1.2EXAMPLE
1 / 4 · Meet the photo app and token issuer

We assume the app has checked the server’s TLS identity. Now the server asks who is connecting.

Photo appToken issuerKey stays herePrivate key
Photo appPrivate key stays at the app

Offline teaching example. TLS, certificate-chain and token validation results are selected inputs; this page is not a TLS connection or an OAuth server.

What happens if you change this?

Predict whether the request will pass. Change one choice to see why; use Restart to restore the original example.

4 / 4
04
Keep identity and permission separate

TLS possession proof does not, by itself, grant access to pictures. OAuth permission and registered-client checks have separate jobs.

Show a card, then prove you own its keyTLS possession proof does not, by itself, grant access to pictures. OAuth permission and registered-client checks have separate jobs.Photo appToken issuerKey stays herePrivate keyCertificate APublic key ACan be copiedTLS proof verifiedProof of a held key ≠ permission to fetch pictures

Key idea: A certificate is public. A successful TLS proof needs the corresponding private key.

Terms
mutual TLS
A secure connection where the server checks a client’s certificate and proof of its secret key, as well as the client checking the server.
certificate-bound token
A permission note that works only with the particular public certificate and corresponding private key.

Look up a term in the glossary ↗

Rules & examples

These reference examples may differ from the selected experiment.

  • The normal server authentication remains required. Client Certificate, CertificateVerify and Finished checks add the client proof.
  • This offline model selects TLS verification results. It does not run a TLS handshake.

Bounded offline teaching example. TLS, X.509 and token validation results are assumed or selected; no network handshake runs here.

Sources
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

All chapters in RFC 8705

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗