A credential presented to a service is either a reference to state the issuer holds, or a self-contained assertion the verifier evaluates on its own. Where does the authority live in each shape, what exactly does an assertion freeze at the moment it is minted, and why does the choice between the two shapes not change what happens when the credential is stolen?

## Two shapes a credential can take Strip away formats and protocols and every credential a client presents is one of two things. A **reference** is a meaningless value — a handle, an identifier — that points at a record the issuer owns. The verifier learns nothing from the value itself; it asks the authoritative store *who is this, and what was decided about them*. Authority lives in that store. An **assertion** is a statement — "this principal is X, belongs to tenant Y, was granted Z" — protected so that tampering is detectable and the origin is provable, typically by a signature or a MAC. The verifier reads the statement, checks the protection against a key it already trusts, and decides. Authority lives in the **key**, not in any state. Everything else about the two designs is downstream of that one difference. ## Why an assertion is the only shape that crosses a trust boundary A reference is only meaningful to a party that can resolve it. Resolving it requires two things a verifier may not have: *reachability* of the issuer's state, and *entitlement* to query it. Between services you control, both are cheap assumptions. Across an organisational boundary — a partner, a customer's own infrastructure, an offline or intermittently connected device, a component deliberately isolated from your data plane — neither holds. Making the reference longer or more random does not help; unresolvable is unresolvable. An assertion replaces a reachability relationship with a **key-trust relationship**. The verifier needs the issuer's public key (or a chain terminating in something it trusts) and nothing else at decision time. Trust becomes transitive without connectivity. That is the whole reason federated and cross-domain identity is assertion-shaped: it is not an optimisation, it is the only shape that functions when the verifier cannot see the issuer's state. ## An assertion is a frozen authorization decision Here is the claim worth carrying into an interview. When an issuer mints an assertion carrying roles, scopes, entitlements or tenancy, it has already *performed an authorization decision* — it consulted authoritative state, evaluated policy, and recorded the outcome. The client then replays that recorded outcome to verifiers that never see the inputs. So the gap between issuance and use is not latency and not a caching inefficiency. It is an **authorization defect with a known duration**: for the credential's lifetime, verifiers enforce a decision made against inputs that may already be false. A role removed, a tenant suspended, a contract terminated, an account compromised and locked — the assertion keeps asserting the old world, and a correctly implemented verifier keeps honouring it, because verification proves *integrity and origin*, never *currency*. A signature says "the issuer said this and nobody altered it", which is silent on whether the issuer would still say it. The consequence is a rule, not a tuning knob: **for high-impact actions, re-evaluate authoritative state at the moment of the action**, regardless of how short the credential's lifetime is. Shortening the window narrows the exposure; it never converts a snapshot into a decision. Reading a public catalogue can tolerate a stale belief; moving money, changing a recovery address or granting someone else access cannot, and those operations should consult live state even when the credential says they are permitted. ## What this does to the authentication/authorization split The split this concept protects is: authentication establishes *who*, authorization decides *what may be done*, evaluated by the party that owns the resource. A credential is authentication evidence. The moment fine-grained permissions are packed into it, the credential silently becomes the authorization decision — taken by the issuer, at issuance, for every verifier at once. Policy is then spread across issuers, frozen for a lifetime, and impossible to change centrally. The design consequence: carry identity plus a small number of coarse, slow-changing claims; make the fine-grained decision at the resource against current state. The same logic explains why an assertion should name the verifier it was minted for — an assertion any service accepts merely because it verifies is a credential without an intended audience. ## Bearer versus proof of possession The axis that actually moves the threat model is orthogonal to reference-versus-assertion. Both shapes are, by default, **bearer** credentials: possession is authority, the credential authenticates itself rather than the party holding it, and a copy is as good as the original. Neither shape detects theft, and neither shape is inherently safer than the other when a credential leaks from a log, a proxy, a browser store or a backup. **Proof of possession** changes that. The credential is bound to a secret the legitimate holder controls — a private key named in or hashed into the credential, or the TLS channel it was issued over. The verifier then demands two things: a valid credential *and* fresh evidence that the presenter controls the bound secret, typically a signature over request-specific material such as a nonce, timestamp, method and target. A stolen copy alone is inert; the attacker must also extract non-exportable key material, which is a materially harder compromise. Binding is not free. Every client needs key management and a place to keep the secret; intermediaries that terminate and re-originate connections break channel binding; the freshness material must be checked to prevent replay; clock skew becomes a correctness issue; and the binding check must fail closed — a verifier that accepts the credential when the proof is missing has silently reverted to bearer semantics for every caller. ## How to decide Ask three questions in order. Can every verifier reach and query authoritative state? If no, you need an assertion. How stale may this operation's authorization inputs be? That answer, not the credential shape, dictates where you re-check live state. And what happens if a copy of this credential leaks? If "complete impersonation" is unacceptable, bind it — that decision matters more than the reference-versus-assertion choice it sits on top of.