Evidence Bound Authentication

Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.

Version

v1 · 2026-08-24 · History

Solution archetype #

418

Problem family

Identity, Provenance & Integrity Failure

Problem subfamily

Source Authentication & Provenance Evidence

What this archetype solves

Evidence-Bound Authentication is for moments when a system must decide whether an asserted identity or origin is good enough to rely on. The key word is binding. A name, badge, token, account, signature, source label, provenance claim, or custody note is not enough by itself; the intervention asks whether admissible evidence binds that assertion to the present claimant, artifact, record, request, or source.

The archetype therefore sits before downstream reliance. It does not decide every permission, truth claim, or credibility judgment. It produces a scoped verdict that a later access-control, evidence-weighting, publication, transaction, or custody process can consume.

Core pattern

1. State the identity or origin claim precisely.
2. Define admissible evidence and the required assurance level.
3. Collect or receive evidence through integrity-preserving channels.
4. Bind the evidence to the current claimant and context.
5. Check issuer, custody, signature, liveness, freshness, expiry, revocation, replay, and scope as relevant.
6. Emit a verdict: accepted, rejected, inconclusive, expired, revoked, step-up required, out of scope, or manual review.
7. Couple that verdict only to the downstream action it actually supports.
8. Preserve auditability, appeal, recovery, and minimum necessary disclosure.

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A system must decide whether to trust, admit, weigh, route, or act on a claim about who or what something is, where it came from, who committed to it, or whether it is the same source previously known. Names, labels, accounts, credentials, documents, signatures, custody records, and metadata can be copied, forged, stale, misbound, misrouted, or true only for a narrower scope. Without an authentication archetype, downstream access and trust decisions treat assertions as facts, while provenance reviews, authorization rules, and general screening processes compensate too late or answer a different question.

Applicability expression7 distinct conditions

Identity or origin claimandDownstream claim relianceandSpoofable claimandRepeatable evidence checkandDual authentication errorsandContext-scoped verdictandLegible decision state

Algebraic1∧2∧3∧4∧5∧6∧7

groundedpartly groundedopen

7 conditions, all required.

7Required in every casenumbered 1–7

These hold no matter which pattern applies.

1

Identity or origin claim · grounded

An actor, account, object, record, message, source, or credential asserts identity or origin. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

and — also required

2

Downstream claim reliance · grounded

A downstream access, weight, responsibility, custody, payment, acceptance, or attribution decision depends on the claim. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

and — also required

3

Spoofable claim · grounded

The claim can be imitated, replayed, substituted, stolen, forged, stale, delegated, or confused with a nearby entity. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

and — also required

4

Repeatable evidence check · grounded

Admissible evidence can be checked through a repeatable procedure rather than accepted by assertion alone. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

and — also required

5

Dual authentication errors · open

False acceptance and rejection both matter, with balance governed by risk, burden, fairness, and privacy. more

and — also required

6

Context-scoped verdict · grounded

The verdict is scoped by freshness, capability, context, custody, trust anchor, or assurance level. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

and — also required

7

Legible decision state · grounded

A legible decision state is required before a downstream system proceeds. more

primeAuthentication— Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.

Coverage

6 of 7 conditions grounded · 1 open.

Read the methodology · Download the trigger-logic data

Key components

Component	Description
Asserted Identity or Origin Claim ↗	The process begins by naming what is actually being asserted. Is the claim that this user is a particular account holder, that this package came from a particular publisher, that this artwork is the asserted object, that a message came from a named service, or that a record passed through a particular chain of custody? Without a precise claim, evidence checks drift into vague trust judgments.
Admissible Evidence Standard ↗	The evidence standard says which proofs count and how strong they must be. A low-risk forum account may need little evidence; a privileged database action, legal record, medical portal, or custody transfer requires stronger evidence and clearer auditability. The evidence standard must balance false acceptance, false rejection, privacy cost, accessibility, and operational burden.
Evidence-to-Claim Binding Rule ↗	This is the distinctive center of the archetype. Evidence can be valid but still not bind the right thing. A credential may be genuine but stolen; a signature may be valid but for the wrong audience; a provenance record may prove a similar object but not this one; a biometric may show a body was present but not that the action was authorized. The binding rule explains exactly how evidence supports this claim in this context.
Authentication Verdict Taxonomy ↗	Binary pass/fail is often too crude. Useful verdicts include accepted, rejected, inconclusive, expired, revoked, mismatched, out of scope, challenged, step-up required, and manual review. A richer taxonomy lets systems remediate legitimate cases without weakening the standard.
Verdict-to-Trust Coupling Rule ↗	A successful authentication verdict is not universal trust. It may allow this session, this transaction, this evidence weight, this custody transfer, or this limited publication. The coupling rule prevents authentication from silently becoming broad authorization, legitimacy, competence, or truth.

Common mechanisms

Authentication can be implemented through credential verification, authentication brokers, certificate-chain validation, digital signatures, challenge-response protocols, multi-factor workflows, liveness checks, federated identity assertions, provenance-chain review, chain-of-custody review, and zero-knowledge or selective-disclosure proofs.

Mechanisms should be chosen by claim type and adversary model. Digital requests often need freshness and replay resistance. Physical artifacts need custody and origin evidence. Institutional credentials need issuer and revocation checks. Privacy-sensitive settings need minimum-disclosure proofs or trusted intermediaries.

Parameter dimensions

Important design parameters include assurance level, evidence type, issuer trust, verifier independence, revocation latency, session lifetime, risk tier, appeal burden, disclosure amount, audit retention, fallback path, and the tolerated balance between false acceptance and false rejection.

The same system may use several parameter bands. Routine access can use low-friction evidence, while high-risk actions trigger step-up authentication. Artifact provenance may require stronger evidence for sale or publication than for internal triage. Age verification may require only a threshold verdict rather than a full identity disclosure.

Invariants to preserve

The archetype should preserve these invariants:

• the claim being authenticated remains explicit;
• the evidence standard is proportional and legible;
• the evidence binds to the current claimant, object, source, request, or context;
• authentication is not confused with authorization or general trustworthiness;
• freshness, revocation, replay, and scope are checked;
• verdicts remain scoped and auditable;
• privacy and minimum necessary disclosure are respected;
• legitimate failures have review, recovery, or appeal paths.

Tradeoffs

Stronger authentication can reduce impersonation, substitution, replay, and provenance fraud, but it also creates friction, cost, latency, privacy exposure, accessibility barriers, and central points of failure. Lightweight authentication improves usability but may push risk into downstream systems that assume identity or origin was firmly established. Federated identity reduces integration cost but shifts trust to issuers and brokers. Privacy-preserving proof reduces exposure but may add complexity and reduce debuggability.

Failure modes

The most common failure is misbinding: a valid proof is accepted for the wrong claimant, context, audience, or time. Another is staleness: a credential or custody record was valid once but is expired, revoked, replayed, or delegated out of scope. A third is authorization conflation: the system treats “authenticated” as “allowed to do anything” or “generally trustworthy.”

Equity and privacy failures are also central. Authentication can exclude legitimate users who lack standard documents, devices, biometrics, or recovery channels. It can also collect more identity data than the verdict requires. A good design uses minimum necessary disclosure, equivalent access paths, appeal, and calibrated assurance tiers.

Neighbor distinctions

Gateway Mediation can host an authentication broker, but gateway routing is broader than authentication. Least-Privilege Access Design decides what an accepted actor may do; authentication decides whether the asserted actor, source, request, or artifact is accepted at all. Hidden-Type Screening tests hidden quality or eligibility; authentication binds identity or origin. Source Provenance Triangulation evaluates reliability and corroboration; authentication asks whether this source or object is the asserted one. Credible Signaling designs hard-to-fake signals; authentication adjudicates whether a particular signal binds to a present claim.

Examples

A software-update system validates publisher signature, package hash, certificate chain, revocation, and audience before installing a package. A court authenticates a record by checking signatures, seals, custody transfers, and metadata before relying on it. A bank triggers step-up authentication for a large transfer, binding a possession factor to the transaction rather than relying on a stale session. A museum authenticates an artifact by linking physical markers, provenance, catalog identifiers, and custody evidence to the asserted object.

Non-examples

A role matrix that grants permissions after login is authorization, not authentication. A test that assesses a known applicant’s skill is screening. A historian deciding which authenticated source is more accurate is provenance triangulation or evidence evaluation. A badge worn only as a symbol is signaling or affiliation unless a procedure checks it and emits a verdict.

Implementation checklist

• What exactly is being asserted?
• What downstream decision depends on the assertion?
• What evidence is admissible and proportionate?
• How does the evidence bind to this claimant, object, request, or source?
• How are freshness, revocation, replay, delegation, and scope handled?
• What verdict states exist besides pass/fail?
• What can each verdict authorize, weight, route, or escalate?
• What evidence is retained, minimized, redacted, or exposed?
• What happens for legitimate users or artifacts that fail ordinary checks?
• How will false acceptance, false rejection, privacy exposure, and adversarial adaptation be monitored?

Common Mechanisms

12 documented mechanisms across 4 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Assessment, Review & Assurance · 6 mechanisms

• Certificate Chain Validation — Establishes that a certificate's key really belongs to the named subject by walking the signed chain from leaf to a trusted root, enforcing each hop's validity, scope, and revocation, and returning a graded verdict.
• Chain-of-Custody Evidence Review — Authenticates an artifact by reconstructing its unbroken, documented custody trail — proving the thing in hand is the same one collected at origin, handled intact and untampered.
• Challenge-Response Authentication — Proves a claimant holds a secret by having them compute the correct answer to a fresh, unpredictable challenge — so possession is demonstrated without the secret crossing the wire, and a captured exchange can't be replayed.
• Credential Verification Workflow — Runs an asserted eligibility or identity claim through a defined sequence of primary-source evidence checks — with a staffed exception lane for the cases the rules can't settle — before a protected offer or access is granted.
• Digital Signature Verification — Confirms that a specific message was signed by the holder of a given key and hasn't changed since — binding content to its signer's key, with tamper-evidence built in, while deliberately leaving key-to-identity trust to a separate step.
• Provenance Chain Review — Authenticates an artifact by tracing its origin and every handoff — accepting it only when the lineage back to a trusted source is complete and unbroken.

Control, Automation & Runtime · 3 mechanisms

• Authentication Broker — Sits between clients and the capability, verifies who is asking, and issues a scoped, short-lived credential that grants exactly the access the request needs — and no more.
• Multi-Factor Authentication — Requires evidence from two or more independent categories — something you know, have, and are — so compromising any single factor is not enough to pass.
• Revocation Status Check — Checks whether an otherwise-valid credential has been revoked, expired, or pushed out of scope since it was issued — so trust is withdrawn the moment its basis changes.

Experiment, Test & Rehearsal · 1 mechanism

• Liveness or Presence Check — Proves a real, live, present subject is producing the evidence right now — so a photo, recording, mask, or deepfake cannot stand in for a genuine presence.

Protocol, Workflow & Routine · 2 mechanisms

• Federated Identity Assertion — Lets one system grant access on the strength of a signed identity assertion from a trusted external identity provider — accepting the provider's authentication verdict instead of re-authenticating the user itself.
• Zero-Knowledge Authentication Protocol — Proves possession of a secret, or the truth of a claim, while revealing nothing beyond the claim itself — authentication without handing over the underlying data.

Compression statement

Define the claim to be authenticated, the evidence admissible for that claim, the verifier and procedure, the freshness and revocation checks, the verdict categories, and the downstream coupling from verdict to trust, access, authority, or weight; then reject, challenge, escalate, or narrowly accept the claim without confusing authentication with authorization, broad credibility judgment, or hidden-quality screening.

Canonical formula: Authenticate(C, E, P, S, T) -> V, where C is an asserted identity/origin claim, E is evidence admissible under policy P, S is the verifier and procedure, T is the time/context of use, and V is a scoped verdict such as accept, reject, challenge, step-up, expired, revoked, mismatch, or inconclusive. Downstream action A may proceed only if coupling_rule(V, risk, scope) permits it.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

• Access Control: Restrict system access.
• Attestation: A verifiable, principal-binding, tamper-evident mark lets a third party confirm who committed to what.
• Authentication: Binding an asserted identity or origin to admissible evidence through a procedure that yields a verdict, before trust, access, or weight is granted.
• Capability Separation: Issuance is restricted to a privileged party while verification is open, tied by a forgery-prevention mechanism.
• Evidence: A defeasible, provenance-bearing relation between an observable trace and a hypothesis about an unobservable state.
• Provenance: A documented, traceable record of an entity's origin and successive custody transfers that establishes authenticity and assigns accountability by linking present state back to first known state.
• Verification: Check that an object conforms to its specification via a defined procedure yielding evidence and a verdict.

Also references 30 related abstractions

• Accountability: Responsibility for actions.
• Adverse Selection: Hidden pre-contractual types make participation under uniform terms systematically more attractive to the types worst for the uninformed side, degrading or unraveling the pool.
• Authority: The recognized, legitimate right to issue binding decisions within a defined scope, distinct from raw coercive force or mere persuasive influence.
• Boundary: Defines system limits.
• Consent: Voluntary agreement.
• Constraint: Limits possibilities to guide outcomes.
• Custody Transfer: A discrete moment at which responsibility for something passes from one holder to another, releasing the first and binding the second through an explicit triggering act.
• Data Integrity: Accuracy and consistency preserved.
• Governance: The durable architecture of authority, accountability, and decision rights through which a group makes binding collective choices and resolves disputes internally.
• Identifier Assignment: Mint a durable handle for an entity and bind it to that entity in a public, queryable record, so future reference can route through the handle without re-describing the entity.

▸ Show 20 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Credential-Based Authentication · implementation variant · recognized

Authenticates a claim by checking a credential, certificate, key, license, badge, or token against issuer, holder, scope, and revocation evidence.

• Distinct from parent: The parent includes provenance, liveness, chain-of-custody, and zero-knowledge forms; this variant centers on issuer-backed credentials.
• Use when: A trusted issuer or registry exists; A portable credential can be presented to a verifier; The credential must be checked for holder binding, scope, expiry, and revocation.
• Typical domains: access management, licensing, professional credentialing, federated identity
• Common mechanisms: credential verification workflow, certificate chain validation, revocation status check

Provenance-Based Authentication · domain variant · recognized

Authenticates an artifact, record, source, or batch by checking origin, custody, integrity, and transfer evidence.

• Distinct from parent: It emphasizes custody, origin, and integrity chains; the parent includes actor, device, account, and source authentication too.
• Use when: The object or record claims a specific origin or continuity; Custody gaps, substitution, forgery, or unauthorized alteration are material risks; The verdict gates evidential weight, sale, publication, acceptance, or handling.
• Typical domains: archives, museum provenance, supply chain, legal evidence
• Common mechanisms: provenance chain review, chain of custody evidence review, signature borne provenance check

Step-Up Authentication · risk or failure variant · recognized

Raises the authentication evidence requirement when context, action risk, anomaly, or privilege exceeds a normal assurance threshold.

• Distinct from parent: The parent defines the whole authentication gate; this variant defines adaptive escalation of evidence.
• Use when: The same claimant performs actions with different risk levels; Anomalous context changes the probability of impersonation or credential theft; Low-friction default authentication must be supplemented for consequential actions.
• Typical domains: banking, platform security, privileged operations, clinical record access
• Common mechanisms: multi factor authentication, challenge response authentication, liveness or presence check

Privacy-Preserving Authentication · governance variant · recognized

Authenticates a required claim while revealing only the verdict or minimum necessary attribute, not the underlying secret or full identity record.

• Distinct from parent: The parent permits many evidence channels; this variant prioritizes selective proof and disclosure minimization.
• Use when: The verifier needs a binary or scoped claim but not the underlying attribute; Disclosure creates safety, privacy, discrimination, or regulatory risk; A cryptographic, escrowed, selective-disclosure, or trusted intermediary proof can produce the verdict.
• Typical domains: age verification, anonymous credentials, whistleblower access, confidential records
• Common mechanisms: zero knowledge authentication protocol, selective disclosure credential check, blinded attestation review

Near names: Authentication, Identity Verification, Origin Verification, Authentication Broker, Credential Verification, Proof of Identity, Authenticity Check.

Editorial Notes

Problem Classification

Classification: Identity, Provenance & Integrity Failure → Source Authentication & Provenance Evidence

Problem kernel: identity claims are trusted through forgeable labels

Rationale: Names and accounts substitute for evidence binding origin, custody, commitment, and continuity to the source actually being assessed.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A system must decide whether to trust, admit, weigh, route, or act on a claim about who or what something is, where it came from, who committed to it, or whether it is the same source previously known. That is a source authentication and provenance evidence problem because Origin, custody, authorship, inherited substrate, or upstream trust cannot be established from evidence that survives copying, transfer, inheritance, and use.

Review outcome: Independent reviewer agreement; high confidence.