Skip to content

Authentication

Prime #
644
Origin domain
Computer Science & Software Engineering
Subdomain
information security → Computer Science & Software Engineering

Core Idea

Authentication is the structural pattern of binding an asserted identity or origin to admissible evidence before granting trust, access, or weight. Someone or something claims to be a particular party — a user, a document, an artwork, a sender, a witness, a patient — and the receiver runs a procedure that takes the claim plus presented evidence (something known, something held, something inherent, something attested by a third party) and outputs binding accepted or binding rejected. The defining commitment is that the procedure links specifically to identity or origin, not to conformance with a specification: authentication asks "is this party or artefact who or what it claims to be?" and stops there. The downstream uses of the authenticated entity are governed by other patterns — authorisation, access control, evaluation — but each of those requires authentication as its precondition.

The structural pattern recurs because three conditions recur everywhere. Asymmetric information about identity: the receiver does not directly observe the claimant's identity, while the claimant does. Cost-asymmetry of impersonation: successful impersonation pays off, and verification costs less than the harm of accepting impostors. Repeatable reliance: the claim is made in a context where the identity-binding will be relied upon for downstream decisions. When these three conditions hold, an authentication procedure appears, in whatever vocabulary the domain has — provenance, chain of custody, due diligence, self/non-self discrimination — because the structure is the same even where the words differ. The pattern is the procedure that converts an unverified claim of identity into a binding, and it sits structurally before every use to which that identity will be put.

How would you explain it like I'm…

Are You Really You?

Before letting someone in, you check that they really are who they say. A secret password, or a face you know, helps you decide to trust them. If the check fails, you don't let them in.

The Identity Check

Authentication is checking whether someone or something really is who or what it claims to be, before you trust it or let it in. The one claiming runs into a procedure that looks at evidence: something they know (a password), something they have (a key or badge), something they are (a fingerprint), or something a trusted third party vouches for. The procedure then answers just one question — is this really them? — and stops there. It does not decide what they're allowed to do afterward; that's a different step. But every later step depends on this one working first.

Binding Claim to Evidence

Authentication is the pattern of binding an asserted identity or origin to admissible evidence before granting trust, access, or weight. Someone claims to be a particular party — a user, a document, an artwork, a sender, a witness — and the receiver runs a procedure that takes the claim plus presented evidence (something known, held, inherent, or attested by a third party) and outputs 'binding accepted' or 'binding rejected.' The defining commitment is that the procedure links specifically to identity or origin, not to conformance with a specification: it asks 'is this party or artifact who or what it claims to be?' and stops there. What you do with the authenticated entity afterward — authorization, access control, evaluation — is governed by other patterns, but each of those needs authentication first. The pattern recurs wherever three conditions hold: asymmetric information about identity, a payoff to impersonation that outweighs verification cost, and repeatable reliance on the binding.

 

Authentication is the structural pattern of binding an asserted identity or origin to admissible evidence before granting trust, access, or weight. Someone or something claims to be a particular party — a user, a document, an artwork, a sender, a witness, a patient — and the receiver runs a procedure that takes the claim plus presented evidence (something known, something held, something inherent, something attested by a third party) and outputs binding accepted or binding rejected. The defining commitment is that the procedure links specifically to identity or origin, not to conformance with a specification: authentication asks 'is this party or artefact who or what it claims to be?' and stops there. The downstream uses of the authenticated entity are governed by other patterns — authorization, access control, evaluation — but each requires authentication as its precondition. The pattern recurs because three conditions recur everywhere. Asymmetric information about identity: the receiver does not directly observe the claimant's identity, while the claimant does. Cost-asymmetry of impersonation: successful impersonation pays off, and verification costs less than the harm of accepting impostors. Repeatable reliance: the claim is made where the identity-binding will be relied upon for downstream decisions. When these hold, an authentication procedure appears in whatever vocabulary the domain uses — provenance, chain of custody, due diligence, self/non-self discrimination — because the structure is the same even where the words differ. The pattern is the procedure that converts an unverified claim of identity into a binding, and it sits structurally before every use to which that identity will be put.

Structural Signature

the asserted identity or origin — the admissible evidence channels (known, held, inherent, attested) — the verification procedure — the trust anchor at which the chain bottoms out — the freshness condition resisting replay — the binding verdict that licenses downstream trust for a bounded window

The pattern is present when each of the following holds:

  1. An asserted identity or origin. A party or artefact claims to be a particular entity, and the binding is specifically to identity or origin — not to conformance with a specification.

  2. Admissible evidence. Evidence is presented across one or more channels — something known, something held, something inherent, something attested by a third party — that the receiver will weigh.

  3. A verification procedure. A procedure takes the claim plus the evidence and outputs a verdict, with an explicit threat model naming which impostor classes it stops and which it admits.

  4. A trust anchor. The chain of evidence bottoms out at a root — a root certificate, identity authority, notary, recognised expert — whose compromise invalidates everything downstream.

  5. A freshness condition. The procedure must resist replay of past-valid evidence, via nonces, timestamps, seals, or expiry windows.

  6. A binding verdict. The output is binding-accepted or binding-rejected (or a graded confidence), which licenses downstream trust, access, or weight for some window — converting an expensive per-interaction check into amortised trust-on-record.

These compose so that the pattern sits structurally before every use of the identity (authorisation, evaluation), and its verdict carries a normative residue — trust granted — that distinguishes it from a bare conformance check.

What It Is Not

  • Not verification. Verification checks an artefact against its specification ("does this conform?"); authentication binds an identity or origin to evidence ("is this who or what it claims to be?"). Conforming content from a forged identity passes verification and fails authentication. See verification.
  • Not access_control. Access control (authorisation) decides what an identity may do once established; authentication establishes the identity in the first place. Authentication is the precondition; access control is the downstream gate.
  • Not provenance. Provenance is the recorded chain of origin of an artefact; authentication is the procedure that binds a claimed origin to admissible evidence and outputs a verdict. Provenance is one evidence channel the authentication procedure may weigh, not the procedure itself.
  • Not signaling. Signaling conveys a costly-to-fake quality; authentication binds a specific identity, and admits innocent and attested evidence, not only costly signals. One reads a quality; the other resolves a claim of who.
  • Not validation. Validation asks whether something meets its intended purpose or is well-formed; authentication asks whether a claimed identity is genuine. A valid, well-formed document can still be from a forged sender.
  • Common misclassification. Conflating authentication with authorisation, so an over-permissive permission rule is treated as secure because authentication is strong, or a forged identity is granted access because authorisation looked careful. The tell: does the step establish identity (authentication) or entitlement (authorisation)?

Broad Use

  • Information security — passwords, hardware tokens, biometrics, certificate chains, and challenge-response protocols that bind a claimed identity to evidence.
  • Law and finance — signature verification, notarisation, identity documents, due-diligence checks, and chain-of-custody for evidence.
  • Art and collectibles — provenance research, stylistic analysis, materials testing, and expert attestation that bind a claimed origin to evidence.
  • Medicine — patient identification before procedures, sample chain-of-custody, and accreditation of providers.
  • Scholarship and journalism — source authentication, document and image verification, and the vouching of anonymous sources.
  • Biology and social systems — molecular self/non-self discrimination as a literal authentication mechanism, and vouching, credentialing, and reputation tokens as their social counterparts.

Clarity

Naming authentication as a distinct structural step clarifies a chain of three operations that are often conflated. Authentication asks "is this who or what it claims to be?" Authorisation asks "given who it is, what may it do?" Verification asks "does this artefact conform to its specification?" The chain only works if each step is named, because the failure of one is invisible from the standpoint of the others: an over-permissive authorisation rule is meaningless if authentication can be bypassed, and a process that grades content is meaningless if the author's identity was forged. Separating the steps locates a failure precisely rather than letting it hide behind a neighbouring concern.

A second clarity dividend is that the authentication frame makes visible which evidence is being weighed. The taxonomy of evidence channels — something known, held, inherent, or attested — surfaces blind spots ("we rely entirely on something-known, so a phishing attack breaks us") and identifies fixes ("add something-held or something-inherent"). This converts a vague sense that a procedure is "secure" or "insecure" into a structured audit of which channels it draws on and which impostor classes each channel stops. The frame thereby turns trust from an undifferentiated attitude into a procedure with named inputs and a verdict, and it makes the strength of that verdict a function of the channels combined rather than of confidence alone.

Manages Complexity

The structural payoff is the trust-on-record contract: once an entity has authenticated, the receiver may treat it as that identity for some subsequent window without redoing the procedure on every interaction. This shifts the cost of identity from per-interaction to per-session, which is what makes large-scale systems tractable. The same shift operates at human scale: notarising a document once converts every future question about its authenticity from "verify it afresh" to "refer to the record." The complexity-management win is that the expensive binding step is performed once and amortised over many subsequent reliances.

The frame also handles graded trust rather than only binary verdicts. Multiple evidence channels scale confidence; provenance chains have stronger and weaker links; inherent-evidence scores are probabilistic. The structural pattern accommodates a verdict that is a confidence level and binds the level of trust to the strength of the procedure, so that a high-stakes reliance can demand more channels and a low-stakes one fewer. This lets a system tune the cost of authentication to the cost of being wrong, allocating expensive multi-channel procedures where impersonation is most damaging and cheap single-channel ones where it is not — a structural lever that a purely binary notion of "authenticated or not" would hide. The complexity a real system would otherwise face — when to re-authenticate, how much evidence to demand, how long a binding lasts — is organised by the single contract of trust-on-record with a strength-calibrated verdict.

Abstract Reasoning

Authentication enables a family of structural reasoning moves. Threat-model reasoning: for any procedure, the questions are which impostors it stops and which it lets through, which forces enumeration of attack classes — replay, phishing, forgery, side-channel — and a defence matrix against them. Trust-anchor reasoning: every authentication chain bottoms out at a root anchor — a root certificate, a national identity system, a trusted notary, a recognised expert — and identifying the anchor exposes systemic fragility, because if the anchor is corrupted everything downstream is compromised.

Two further moves complete the family. Freshness reasoning: procedures must resist replay of past-valid evidence, so nonces, timestamps, sealed envelopes, and tamper-evident seals are all domain-specific instantiations of the same freshness requirement. Provenance-as-graph reasoning: a chain of custody is literally a graph, and breaks in the graph are the authentication failures, so reasoning about provenance is reasoning about graph connectivity. These moves transfer cleanly: a curator's intuition about a break in provenance has the same shape as a cryptographer's intuition about a break in a certificate chain, and a forensic scientist's intuition about chain-of-custody is structurally identical to a systems engineer's intuition about audit logs. Each is the same recognition — a claim of identity must be bound to evidence through a procedure whose anchor and freshness can be interrogated — and the reasoner who holds the structure applies it wherever an identity claim must be checked. The pattern's normative residue — a verdict licenses trust, and trust carries weight — is what distinguishes it from a bare conformance check and what places it at the framed end of the spectrum.

Knowledge Transfer

Authentication carries concrete intervention recipes across domains, and the recipe is the same six steps wherever it is applied: identify the asserted identity or origin; enumerate the evidence channels available (known, held, inherent, attested); choose a procedure with an explicit threat model naming which impostor classes it stops; locate the trust anchor and assess its fragility; add freshness defences against replay; and bind the verdict to a downstream contract that specifies what "authenticated" entitles the bearer to, and for how long. The steps travel because the structure travels — every instance has a claim, channels, a procedure, an anchor, a freshness requirement, and a verdict, whatever the substrate calls them.

The transfers are non-trivial in practice. A clinician who learns the frame from information security recognises that a patient wristband plus verbal confirmation is a two-channel procedure with a known anchor (admissions intake), a specific threat model (patient swap during transport), and a known freshness window (per-shift handoff) — and can audit it for thinness in exactly those terms. An appraiser who learns the frame notices that expert attestation plus materials testing plus documented provenance is a multi-channel procedure with a mixed anchor structure, one channel anchored at the expert's reputation, another at a laboratory, another at archival records — and can ask which anchor is most fragile. The four-channel evidence taxonomy is load-bearing across all of these as a sharp lens for diagnosing single-channel thinness, and the trust-anchor question — what would compromise the anchor? — is the recurring vulnerability probe in each. The biological instance, self/non-self discrimination, is a genuine occurrence of the same claim-evidence-verdict structure, though its vocabulary requires translation, which together with the security-and-legal origin and the normative trust-binding load is why the pattern reads as framed: the structure transfers broadly, but it carries a vocabulary and an evaluative weight that travel with it.

Examples

Formal/abstract

A TLS certificate-chain handshake is the canonical worked instance and exercises every slot of the signature. The asserted identity or origin is a web server's claim to be a particular domain. The admissible evidence channels are something-held (the server's private key) and something-attested (a certificate signed by a certificate authority binding the domain to the corresponding public key). The verification procedure is the chain validation the client runs: it checks that the server can prove possession of the private key (via a signature over fresh handshake data), and that the certificate is signed by a CA whose certificate is in turn signed up to a trusted root — an explicit threat model naming which impostors it stops (a man-in-the-middle without the private key, an attacker without a CA-signed certificate) and which it admits (an attacker who has compromised a CA or stolen the key). The trust anchor is the root certificate baked into the client's trust store: the chain bottoms out there, and compromise of that root invalidates everything below it — the systemic fragility the structure exposes. The freshness condition resists replay: the server signs a client-supplied nonce, so a recording of a past valid handshake cannot be replayed to impersonate the server. The binding verdict is binary-accepted-or-rejected and licenses downstream trust for the session — the trust-on-record contract that amortises the expensive binding over many subsequent requests rather than re-authenticating each one. The intervention the structure prescribes: enumerate the channels (here two), locate the anchor and probe it ("what would compromise this root?"), and add freshness — the same six-step recipe in every substrate.

Mapped back: The domain claim is the asserted identity, the private key and CA signature are the evidence channels, chain validation is the procedure, the root certificate is the trust anchor, the nonce is the freshness condition, and the session verdict is the binding — authentication in its information-security origin.

Applied/industry

Patient identification before a clinical procedure instantiates the identical claim-evidence-verdict structure in medicine. The asserted identity or origin is the claim that this patient on the table is the one for whom the surgery was scheduled. The admissible evidence channels are something-held (a wristband encoding the patient's identifier) and something-inherent-plus-attested (the patient's own verbal confirmation of name and date of birth, attested against the chart) — a deliberately two-channel procedure. The verification procedure is the pre-operative time-out: a nurse cross-checks wristband, verbal confirmation, and the procedure record, with an explicit threat model naming the impostor class it stops (a patient swap during transport between ward and theatre, a chart mix-up). The trust anchor is the admissions-intake process that issued the wristband and populated the record; if intake bound the wristband to the wrong record, everything downstream is compromised — the same anchor-fragility probe a cryptographer applies to a root certificate. The freshness condition is the per-shift, per-handoff re-confirmation: identity is re-verified at each transfer rather than trusted indefinitely, resisting the "replay" of a stale identification from an earlier ward. The binding verdict licenses the procedure to proceed and is recorded — trust-on-record for the duration of the operation. A clinician who learns the frame from information security can audit this procedure in exactly those terms: it is two-channel (thin if one channel fails — an unconscious patient cannot give verbal confirmation, collapsing to single-channel wristband), with a known anchor and a known freshness window, and the fix for the thinness is to add a channel (a photo on the record, biometric confirmation). The same four-channel taxonomy and trust-anchor probe transfer to art authentication (expert attestation plus materials testing plus documented provenance, a multi-channel procedure with a mixed anchor structure) and to journalism (source authentication and the vouching of anonymous sources).

Mapped back: The patient-is-who-they-claim assertion is the asserted identity, wristband and verbal confirmation are the evidence channels, the surgical time-out is the procedure, admissions intake is the trust anchor, per-handoff re-confirmation is the freshness condition, and the recorded go-ahead is the binding — authentication in clinical practice, audited by the same channel and anchor questions as a certificate chain.

Structural Tensions

T1 — Authentication versus Authorisation (scopal). Authentication binds who or what a party is; authorisation decides what it may do given that identity — and the prime stops at the first. The boundary is identity-binding versus permission-granting. The characteristic failure is conflating them, so an over-permissive authorisation rule is treated as secure because authentication is strong, or a forged identity is granted access because authorisation looked careful. Diagnostic: does the step establish identity (authentication) or entitlement (authorisation)? Each fails invisibly from the other's standpoint, so they must be named and checked separately.

T2 — Authentication versus Verification (scopal). Authentication binds to identity or origin; verification checks conformance to a specification — its nearest neighbour, but a different question. The boundary is identity versus conformance. The failure mode is running one when the other is needed: verifying that content meets a spec while the author's identity was forged, or authenticating the sender while never checking the message conforms. Diagnostic: is the question "is this who it claims to be?" (authentication) or "does this meet its specification?" (verification)? A valid identity with non-conforming content, or conforming content from a forged identity, each passes one check and fails the other.

T3 — Verification Cost versus Impersonation Harm (measurement). The pattern is worth running only where verification costs less than the harm of accepting an impostor, and the verdict's strength should be calibrated to the stakes — multi-channel where impersonation is damaging, single-channel where it is not. The boundary is the cost-of-being-wrong. The failure mode is uniform authentication strength: heavy procedures where the harm is trivial (wasting effort) or thin ones where it is severe (admitting impostors). Diagnostic: does the procedure's strength match the cost of a false accept for this interaction? Mismatched calibration either over-spends on low-stakes checks or under-protects high-stakes ones.

T4 — Binding Verdict versus Freshness Window (temporal). The trust-on-record contract amortises an expensive binding over a window so it need not be redone each interaction — but the longer the window, the more a past-valid credential can be replayed. The boundary is the freshness window's width. The failure mode is binding once and trusting indefinitely, so a stale or replayed credential is accepted long after it ceased to prove identity (a captured handshake, an unrevoked session, an un-reaffirmed directive). Diagnostic: does the procedure resist replay of past-valid evidence via nonces, timestamps, or expiry, and is the trust window short enough that a stale binding cannot do harm? Amortisation and replay-resistance trade against each other.

T5 — Trust Anchor Concentration versus Anchor Fragility (coupling). Every authentication chain bottoms out at a root anchor whose compromise invalidates everything downstream — the concentration that makes the chain efficient also makes the anchor a single point of catastrophic failure. The boundary is the anchor. The failure mode is reasoning about the procedure's strength while ignoring that a corrupted root (a compromised CA, a mis-issued wristband at intake, a captured notary) silently validates every impostor below it. Diagnostic: what would compromise the anchor, and what fails if it does? The chain is only as trustworthy as its root, and a strong procedure on a fragile anchor is fragile.

T6 — Single-Channel Thinness versus Multi-Channel Robustness (scalar). Confidence scales with the number of independent evidence channels (known, held, inherent, attested), so a procedure that relies on one channel is thin and collapses when that channel fails. The boundary is channel count and independence. The failure mode is a nominally two-channel procedure that degrades to one in practice — an unconscious patient who cannot give verbal confirmation, a phished password that defeats something-known — leaving the binding unsupported. Diagnostic: how many independent channels does the procedure actually combine, and does it collapse to one under foreseeable conditions? Single-channel thinness, especially when a second channel can silently drop out, is the recurring weakness the taxonomy surfaces.

Structural–Framed Character

Authentication sits on the framed side of the structural–framed spectrum, at the midline — aggregate 0.5, with every diagnostic at 0.5. It is a balanced hybrid: a real claim-evidence-verdict structure underneath, wearing a security-and-legal frame with a normative trust-binding load. The structural core is genuine — an asserted identity, admissible evidence channels (known, held, inherent, attested), a verification procedure, a trust anchor, a freshness condition, and a binding verdict — and it reaches forensics, art authentication, medicine, journalism, and even molecular self/non-self discrimination.

Every diagnostic reading 0.5 reflects a pattern that is broadly transferable but carries its frame with it. Vocab_travels is 0.5 because the home register — credentials, trust anchors, threat models, replay resistance — has a security accent that needs translation into a clinical or curatorial setting, though the six-step procedure ports. Evaluative_weight is 0.5 because the verdict carries a normative residue: a binding licenses trust, and trust is granted, which distinguishes it from a bare conformance check, even though the procedure itself is neutral machinery. Institutional_origin is 0.5 because the concept arose in information security and law rather than as a formal or physical regularity. Human_practice_bound is 0.5 because most instances presuppose the human practice of granting access or weight, though the biological case — the immune system's self/non-self recognition — is a genuine non-human occurrence of the same claim-evidence-verdict structure that keeps it off a full 1.0. Import_vs_recognize is 0.5 because invoking the prime imports an interpretive frame — bind identity to evidence before granting trust, enumerate the channels, probe the anchor — rather than merely recognising a pattern already present. The genuine relational core and the real biological instance keep it from the framed extreme; the security-legal origin and the trust-binding normative load are what hold it at the balanced 0.5 the frontmatter records.

Substrate Independence

Authentication is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. The claim-evidence-verdict structure is genuine — an asserted identity or origin, admissible evidence channels (known, held, inherent, attested), a verification procedure, a trust anchor, a freshness condition, and a binding verdict — and it reaches forensics, art and collectibles authentication, medicine, scholarship and journalism, and even molecular self/non-self discrimination, where the immune system instantiates exactly the same structure with no human practice involved. That genuine biological occurrence is what carries the breadth above the report- and institution-bound primes. The transfer carries concrete intervention recipes, not just vocabulary: the same six-step procedure and the four-channel evidence taxonomy let a clinician audit a patient-identification time-out and an appraiser audit an artwork's provenance in identical trust-anchor terms. What holds the composite below a 5 is a security-and-legal home register (credentials, threat models, replay resistance) that needs translation into clinical or curatorial settings, and a normative residue — a binding licenses trust, and trust is granted — that distinguishes it from a bare conformance check and keeps it from the pure-structural pole.

  • Composite substrate independence — 4 / 5
  • Domain breadth — 4 / 5
  • Structural abstraction — 4 / 5
  • Transfer evidence — 4 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Authenticationsubsumption: Capability SeparationCapabilitySeparationdecompose: ProvenanceProvenance

Foundational — no parent edges in the catalog.

Children (2) — more specific cases that build on this

  • Capability Separation is a kind of Authentication

    capability_separation's cross-ref is attestation and its nearest is traceability (0.892), both of which the file severs. But the deeper load-bearing relation the file draws is to authentication: capability_separation is the issue/verify-asymmetry ARCHITECTURE within which authentication's deliberate verifiable mark operates, and a public-key signature "exhibits both." This is closer to a sibling than a clean is-a. Recording child_of authentication is the medium-conviction read (issue/verify split presupposes a verifiable-mark mechanism); a sibling_of attestation reading is the alternative. Flagging medium because the direction is genuinely arguable -- LEAVE is acceptable if reviewers prefer not to force it.

  • Provenance decompose Authentication

    The file: provenance is 'one evidence channel a multi-channel authentication procedure weighs' — input to authentication, not the procedure. provenance is a major existing prime (broader: art, data lineage), so this is a part-of/uses, not a reparent.

Neighborhood in Abstraction Space

Authentication sits among the more crowded primes in the catalog (30th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Identity Matching & Lookup (10 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The embedding-nearest prime is verification, and the two form a triad with authorisation that the prime exists to keep apart. Verification checks an artefact against its specification — does this conform to what it is supposed to be or do? Authentication binds an asserted identity or origin to admissible evidence — is this party or artefact who or what it claims to be? The two answer different questions about the same object and can each pass while the other fails: a message can conform perfectly to its format specification (verification passes) while its claimed sender is forged (authentication fails), and a genuinely-authenticated sender can transmit non-conforming content (authentication passes, verification fails). The structural marker is what the check is against: verification against a spec, authentication against an identity claim. The practical hazard of conflating them is running one where the other was needed — checking that content meets a spec while the author's identity was never bound, or authenticating the sender while never checking the message conforms. Both checks are often required, in sequence, and naming them separately is what prevents a failure in one from hiding behind the other.

A second genuine confusion is with access_control (authorisation), the step that follows authentication. Authentication establishes who a party is; access control decides what that party, now identified, may do. The two are routinely fused in casual reasoning ("logging in"), but they fail invisibly from each other's standpoint: a flawless authorisation policy is meaningless if authentication can be bypassed (an attacker who forges an identity inherits all its permissions), and impeccable authentication is wasted if the authorisation rule grants everyone everything. The dependency is strict and ordered — authentication is the precondition, authorisation the consequence — so the structural error is treating a strong authentication as if it secured the system when the entitlement decision is the actual exposure, or hardening authorisation while the identity it gates can be spoofed. Keeping them distinct locates a breach precisely: was the identity forged (authentication), or was a genuine identity over-permitted (authorisation)?

A third worth drawing is against provenance. Provenance is the recorded chain of custody or origin of an artefact — the documented history that establishes where it came from. Authentication is the procedure that takes a claimed origin plus evidence (of which provenance is one channel) and outputs a binding verdict. The relationship is that provenance is input to authentication, not authentication itself: an artwork's documented provenance is one evidence channel a multi-channel authentication procedure weighs alongside materials testing and expert attestation, and the authentication is the act of binding the claimed origin to that and other evidence and rendering a verdict. Treating provenance as authentication mistakes a single evidence channel for the whole procedure — and, dangerously, a documented provenance chain can itself be forged, which is exactly why robust authentication combines it with independent channels rather than resting on it alone.

For a practitioner the distinctions locate both the question and the failure. Confusing authentication with verification runs a conformance check where an identity check was needed (or vice versa); confusing it with access_control secures the wrong half of the login, leaving either identity or entitlement exposed; and confusing it with provenance rests an identity binding on a single, forgeable channel. Asking "is the question who/what is this (authentication), does it conform (verification), or what may it do (authorisation)?" is what keeps the trust chain correctly assembled.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.