Minimal Age Disclosure

Privacy-preserving age-threshold proof architecture for proving 18+ or similar thresholds without disclosing identity, exact date of birth, or a reusable cross-site identifier.

Documentation-first architecture and standards project for minimal age disclosure, anti-correlation, and verifier restraint.

Quick links: Start Here | Project Status | Accepted Architecture Decisions | Document Map | Contributing

At a Glance

This repository argues for a narrow thesis:

services should verify an age threshold, not collect identity.

The project explores a model where a wallet holds a root credential and presents a transaction-bound derived proof to a verifier. The verifier should learn only what is necessary to answer the policy question, such as 18+, and no more.

This is not a production implementation. It is a public documentation set intended to make the architecture, governance model, tradeoffs, and accepted design decisions legible.

Start Here

Choose the path that matches what you need:

• New to the project: read Project Brief, then this README's status and architecture sections.
• Evaluating the core technical model: read Architecture Overview and Root vs Derived Proof Model.
• Assessing verifier obligations: read Minimal-Disclosure Verifier Policy, Verifier Compliance and Retention, and Exception Governance.
• Looking for maturity and accepted decisions: jump to Project Status and Accepted Architecture Decisions.
• Want the full map: see Document Map.

Why It Matters

Many age-verification systems still operate like identity capture systems with an age check attached. That shifts the problem from "prove a threshold" to "collect enough data to feel comfortable," which creates predictable failure modes:

• excessive disclosure becomes normal rather than exceptional
• supporting metadata becomes a tracking and correlation surface
• verifier behavior is under-specified or weakly governed
• retention and exception handling drift beyond the original purpose

This project takes the opposite position:

• prove threshold facts, not identity
• minimize verifier-visible data in the normal flow
• treat anti-correlation as a system requirement, not a nice-to-have
• make governance, conformance, and exception boundaries part of the architecture

Architecture at a Glance

The repository centers on a root credential -> derived proof model within a common trust and governance framework.

flowchart LR
    I["Issuer"] -->|issues root credential| W["Wallet"]
    V["Verifier"] -->|threshold, audience, nonce, policy| W
    W -->|derived transaction-bound proof| V
    V -->|trust validation| T["Trust registry"]
    V -. optional bounded status .-> S["Status service or relay"]

Loading

Normal-Flow Disclosure Target

In the normal flow, the verifier should receive only what is needed to decide whether the threshold requirement is satisfied:

• threshold result
• bounded assurance information
• issuer information only to the minimum extent needed for trust validation
• bounded validity information
• audience binding
• nonce binding
• transaction-bound proof of rightful possession

The normal flow should not disclose:

• exact date of birth
• legal name
• document number
• document image
• stable verifier-visible holder identifier
• stable verifier-visible root credential reference

Principles

• minimum disclosure over convenience-by-default
• privacy by design, including metadata minimisation
• anti-correlation as a first-class architectural objective
• compatibility and deployment realism where possible
• explicit treatment of tradeoffs and residual risks
• verifier restraint enforced through policy, controls, and conformance
• exception paths treated as bounded and governed, not assumed-safe

Project Status

What This Repository Is

• a documentation-first privacy architecture project
• a standards and governance exploration grounded in concrete verifier behavior
• a public design space for privacy-preserving age-threshold proofs

What This Repository Is Not

• not a production implementation
• not a claim of regulatory approval or ecosystem acceptance
• not a statement that one profile solves every deployment context

Current Maturity

Completed baseline:

• layered architecture published
• root credential versus derived proof separation defined
• common governance model and dual-profile framing published
• normative core spec set drafted
• conformance checklist and privacy-negative test catalog drafted
• open implementation-profile questions closed for the current documentation-first phase
• fixture-backed examples added for requests, responses, metadata, retention, exceptions, and recovery
• prototype work intentionally kept at planning level

Recently settled:

• exact issuer resolution boundary
• B0 / B1 / B2 binding modes
• canonical request and response objects
• assurance bucket taxonomy
• freshness and validity granularity
• verifier audit minimum
• exception-path abuse thresholds
• Profile P first proof-family pattern: BBS-style or equivalent unlinkable selective-disclosure proofs
• Profile R rails: OpenID4VCI issuance and OpenID4VP presentation, constrained by the canonical objects

Profiles

The project deliberately separates a more deployment-oriented profile from a more privacy-maximal research profile instead of implying a single design can satisfy both without tradeoffs.

Profile R

Regulator-ready and interoperability-oriented:

• deployment fit first
• standards-aligned issuance and presentation rails
• conservative proof and status assumptions
• clearer audit and conformance expectations

Profile P

Privacy-maximal research profile:

• stronger unlinkability goals
• stronger metadata minimisation
• room for more ambitious proof constructions
• explicit research maturity boundaries

Accepted Architecture Decisions

The most important architecture gaps have been resolved in ADRs and reflected in the specs:

• ADR-0007: Exact issuer resolution for trust validation
• ADR-0008: Minimum holder-binding mechanism for Profile R
• ADR-0009: Canonical ownership of the verifier request object
• ADR-0010: Assurance bucket taxonomy and request semantics
• ADR-0011: Validity granularity and freshness policy boundaries
• ADR-0013: Conditions for non-normal root credential disclosure
• ADR-0014: Verifier audit record minimum
• ADR-0015: Exception-path abuse thresholds and enforcement

These are not minor details. They define whether the architecture remains minimally disclosive under operational pressure.

Document Map

Core Reading

• Project Brief
• Requirements
• Threat Model Seed

Architecture

• Architecture Overview
• Flows and Topology
• Governance and Controls
• Dual Profile Overview
• Potential Final State
• Architecture Review and Changes

Normative Specifications

• Age Threshold Proof Profile
• Minimal-Disclosure Verifier Policy
• Issuer, Wallet, and Verifier Trust Model
• Root vs Derived Proof Model
• Metadata Minimisation
• Conformance Checklist
• Privacy-Negative Test Cases
• Fixture Examples
• Exported JSON Schemas

Governance and Policy

• Exception Governance
• Verifier Compliance and Retention
• Recovery and Compromise
• Policy Pack Outline

Research and Planning

• Open Question Closure Log
• Repo Review and Roadmap
• Revocation and Status Tradeoff Analysis
• Prototype Implementation Plan

How to Read the Repository

If you want a short pass:

1. Read Project Brief.
2. Read Architecture Overview.
3. Read Root vs Derived Proof Model.
4. Check Project Status and Accepted Architecture Decisions.

If you want to review the architecture critically:

1. Read the architecture set under docs/architecture.
2. Review the verifier-policy and conformance documents together.
3. Inspect the ADRs before treating any interface boundary as settled.

Contribution Path

This project is documentation-led. Useful contributions are typically one of:

• challenge a privacy or anti-correlation assumption with a concrete counterexample
• tighten a normative requirement or conformance clause
• identify verifier-side over-collection or retention gaps
• improve policy, trust, or exception governance language
• test an accepted ADR with a clear counterexample or implementation implication

Before proposing major changes, review the architecture docs and relevant ADRs so discussions stay anchored to the current decision record.

See CONTRIBUTING.md, SUPPORT.md, and SECURITY.md.

How to Engage

This repository is likely most useful to:

• digital identity practitioners
• privacy and security engineers
• standards participants
• trust framework and policy stakeholders
• reviewers evaluating whether age assurance can be designed without default identity disclosure

The highest-value engagement is specific critique. If a section overstates privacy properties, understates deployment constraints, or leaves verifier behavior under-governed, that is exactly the kind of feedback this repository should attract.

Roadmap Direction

The current direction is:

1. expand fixture-backed request, response, metadata, retention, exception, and recovery checks
2. map the canonical objects to concrete OpenID4VCI and OpenID4VP payload profiles
3. evaluate concrete Profile P B2 proof libraries against the unlinkability criteria
4. refine UK and EU policy mapping without overstating likely acceptance
5. begin narrow implementation work only after the accepted interfaces pass fixture-backed review