Skip to content

Authentication

Version
v1 · 2026-08-24 · History
Prime #
644
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Information Security → Computer Science & Software Engineering

Core Idea

The pattern of binding an asserted identity or origin to admissible evidence through a verification procedure that outputs a verdict — is this who or what it claims to be? — before trust, access, or weight is granted.

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.

Broad Use

  • Information security: Passwords, hardware tokens, biometrics, and certificate chains bind a claimed identity to evidence.
  • Law and finance: Signature verification, notarisation, and chain-of-custody for evidence.
  • Art and collectibles: Provenance research, materials testing, and expert attestation bind a claimed origin to evidence.
  • Medicine: Patient identification before a procedure and sample chain-of-custody.
  • Journalism: Source authentication and the vouching of anonymous sources.
  • Biology: Molecular self/non-self discrimination as a literal authentication mechanism.

Clarity

It separates three operations otherwise conflated: Authentication (is this who it claims?), authorisation (what may it do?), and Verification (does it conform to spec?) — so a failure in one cannot hide behind the others.

Manages Complexity

The trust-on-record contract performs the expensive binding once and amortises it over a window, shifting identity cost from per-interaction to per-session, with a verdict calibrated to the stakes.

Abstract Reasoning

It enables threat-model reasoning (which impostors does this stop?), trust-anchor reasoning (what would compromise the root?), and freshness reasoning (does it resist replay?).

Knowledge Transfer

  • Security to medicine: A clinician reads a wristband-plus-verbal-confirmation as a two-channel procedure with a known anchor and freshness window.
  • Security to art appraisal: An appraiser reads attestation-plus-testing-plus-provenance as a multi-channel procedure with a mixed anchor.
  • Universally: The four-channel taxonomy (known, held, inherent, attested) is a sharp lens for single-channel thinness.

Example

A TLS handshake binds a server's claimed domain to evidence (a private key plus a CA-signed certificate), validated up to a root certificate, with a nonce resisting replay and a verdict licensing the session.

Relationships to Other Abstractions

Local relationship map for AuthenticationParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.AuthenticationPRIMEDomain-specific abstraction: Secure Channel — includesSecure ChannelDOMAINDomain-specific abstraction: Authentication Failure — presupposesAuthenticationFailureDOMAINDomain-specific abstraction: Federated Identity — presupposesFederatedIdentityDOMAINPrime abstraction: Capability Separation — presupposesCapabilitySeparationPRIMEDomain-specific abstraction: Eye Vein Verification — is a kind ofEye VeinVerificationDOMAINDomain-specific abstraction: Implicit Authentication — is a kind ofImplicitAuthenticationDOMAINDomain-specific abstraction: Multi-factor authentication — is a kind ofMulti-factorauthenticationDOMAINDomain-specific abstraction: Passwordless authentication — is a kind ofPasswordlessauthenticationDOMAINDomain-specific abstraction: Quantum digital signature — is a kind ofQuantum digitalsignatureDOMAINDomain-specific abstraction: Web of Trust — is a kind ofWeb of TrustDOMAINPrime abstraction: Attestation — is a kind ofAttestationPRIME

Current abstraction Authentication Prime

Foundational — no parent edges in the catalog.

Children (11) — abstractions linked here by typed relations

  • Eye Vein Verification Domain-specific is a kind of Authentication

    Eye-vein verification checks a claimed identity against enrolled vascular-pattern evidence using a bounded match decision.

  • Implicit Authentication Domain-specific is a kind of Authentication

    Ordinary-use signals provide identity evidence for continued authentication.

  • Multi-factor authentication Domain-specific is a kind of Authentication

    What makes it its own entry: the domain-specific identity determined by at least two factor categories are genuinely independent and bound to the same claimant, verifier, context, and authorization event under an explicit recovery and threat model.

  • Passwordless authentication Domain-specific is a kind of Authentication

    It remains its own entry because its identity is fixed by the claimant account and verifier, enrollment and binding, authenticator and factor category, public and private key or one-time proof, challenge freshness and origin binding, local user verification, server verification, recovery and revocation and phishing replay and device-loss threat model.

  • Quantum digital signature Domain-specific is a kind of Authentication

    The candidate literally instantiates prime:authentication; its quantum_cryptography restrictions provide the domain-specific residual.

Not to Be Confused With

  • Authentication is not Verification because authentication binds an identity or origin to evidence, whereas verification checks an artefact against its specification; conforming content from a forged identity passes one and fails the other.
  • Authentication is not Access Control because authentication establishes who a party is, whereas access control decides what an established identity may do.
  • Authentication is not Provenance because authentication is the procedure that weighs evidence and renders a verdict, whereas provenance is the recorded chain of origin that serves as one evidence channel.