When a client opens a connection to a broker, what families of proof can it present, and what does each one establish?

## What a connect-time proof settles Authentication is the first stage in the life of a broker connection. The client presents evidence, the broker checks it against its **trust set** — the issuers and credentials it is willing to accept — and if the evidence holds, the connection carries a **principal**: the identity the broker will treat it as for the rest of that connection. Nothing more has happened. The principal has been **named, not empowered**. What it may read, write or administer is decided afterwards by rules written against that name. A cluster with authentication switched on and no rules of its own can still be wide open, and an elaborate rule table means nothing if every client arrives as the same unnamed identity. Two things make this stage behave unlike a web login: - Broker connections are usually **long-lived**. A client opens one and holds it for hours or days, so on many designs the proof is checked when the connection opens and not again while it lasts. - A cluster answers on **more than one address**. The public client edge, an internal or administrative address, and the node-to-node hop between cluster members are each configured separately, so "the broker requires authentication" is never one fact about the whole cluster. ## The families of proof | Family | What the client holds | What the broker must hold | Typical lifetime | |---|---|---|---| | Salted challenge-response password exchange | A name and a secret | A salted verifier per identity | Until someone replaces it | | Client certificate | A certificate and its private key | The issuers it is willing to accept | Months, fixed when issued | | Directory-issued ticket | A ticket obtained from a central directory | A trust relationship with that directory | Hours | | Issuer-signed short-lived token | A token fetched from an external issuer | Material to check the issuer's signature | Minutes to hours | | Delegated platform identity | Nothing durable | Trust in the platform's signer | Minutes | - **A salted challenge-response password exchange** never puts the secret on the wire: the broker sends a challenge, the client answers with a value computed from the secret, and both sides demonstrate they know it without transmitting it. It is the cheapest family to switch on and the most expensive to live with, because every client must somehow be handed a secret and nothing expires on its own. - **Certificate-based client authentication** replaces the shared secret with a key pair. The client presents a certificate and proves it holds the matching private key; the broker derives the identity from that certificate. There is no per-client verifier on the broker side to keep in step — only the issuers it trusts — but every client now holds material that stops working on a fixed date. - **A directory-issued ticket** lets an enterprise directory the organisation already runs do the vouching. The broker trusts the directory rather than any individual client, which suits an estate that already has one and suits nothing else. - **An issuer-signed short-lived token** is minted elsewhere, presented at connect, and expires by itself. The broker keeps no per-client secret at all, only what it needs to check the signature. - **Delegated platform identity** goes one step further: the client was never given a credential. The platform it runs on signs a statement about what it is, and the broker accepts that statement. ## What varies between platforms - Some brokers accept several families at once, each on a different address. Others — particularly a **managed tier**, a rented cluster whose operator is not you — offer exactly one, and the choice is not yours. - Where clients hold long-lived connections, the proof is a connect-time event. Where a cluster also exposes a request-per-call interface, the credential travels with every call instead, and expiry bites immediately rather than at the next reconnect. - How the principal is **named** differs: one design names it by the login the client used, another by the identity carried in the certificate, a third by the subject of the signed statement. Rules are written against that name, so changing mechanism can silently change every identity in the cluster. ## What the question is really testing A candidate who has only read about this says "it uses certificates" and stops. A candidate who has switched it on knows the awkward parts: the family you can enable in an afternoon is the one you will be distributing secrets for forever; the expiring families trade a quiet leak for a scheduled outage; and turning authentication on at the public edge says nothing about the other addresses the same cluster is answering on.