Skip to content

Authentication

Version
v1 · 2026-08-24 · History
Prime #
644
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: Authentication Failure — presupposesAuthenticationFailureDOMAINPrime abstraction: Capability Separation — presupposesCapabilitySeparationPRIMEDomain-specific abstraction: Multi-factor authentication — is a kind ofMulti-factorauthenticationDOMAINDomain-specific abstraction: Passwordless authentication — is a kind ofPasswordlessauthenticationDOMAINDomain-specific abstraction: Protocol for Carrying Authentication for Network Access (PANA) — is a kind ofProtocol for Ca…DOMAINDomain-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 (8) — more specific cases that build on this

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

    The proposed strict upward parent is prime:authentication.

  • Passwordless authentication Domain-specific is a kind of Authentication

    The proposed strict upward parent is prime:authentication.

  • Protocol for Carrying Authentication for Network Access (PANA) Domain-specific is a kind of Authentication

    Authentication is the strict parent by composition and presupposition: PANA carries the identity-evidence exchange to the responsible verifier and maintains its session, but delegates method semantics to EAP and enforcement to another.

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

    The proposed strict upward parent is prime:authentication.

  • Web of Trust Domain-specific is a kind of Authentication

    Authentication is the strongest parent.

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.