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.

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.

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

• 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.
• Certificate Chain Validation
• Chain-of-Custody Evidence Review
• Challenge-Response Authentication
• Credential Verification Workflow
• Digital Signature Verification
• Federated Identity Assertion
• Liveness or Presence Check
• Multi-Factor Authentication
• Provenance Chain Review
• Revocation Status Check
• Zero-Knowledge Authentication Protocol

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.