- Why AXEL Exists
- Design Principles
- What AXEL Is
- What AXEL Is Not
- Protocol Overview
- Core Components
- Optional DNS Integration
- Why IPv6 Matters
- Reference Implementation
- Repository Goals
- Status
- Development
- Architecture Notes
- Threat Model
- Non-Goals
- Roadmap
- Why This Approach Has a Chance
- Contributing
- License
- Project Maturity Note
AXEL stands for Access for eXplicit Enforcement & Labeling.
AXEL is a protocol and reference implementation for machine-readable age-gating policy, privacy-preserving age assurance, and multi-layer enforcement for age-restricted online content.
Rather than relying on vague self-declared labels or fragile application-specific heuristics, AXEL defines a clear, auditable way for services to:
-
declare that content is age-restricted,
-
publish enforcement metadata,
-
request privacy-preserving proof of eligibility,
-
and interoperate with browsers, apps, operating systems, and optional network policy tools.
AXEL is designed to address a real deployment gap: content providers, client software, and policy-enforcement systems all need a common language for age-restriction signals, but existing approaches are fragmented, inconsistent, or trivially bypassed.
Age-restricted content online is usually handled badly.
Common approaches fail in predictable ways:
-
Self-attested checkboxes are trivial to bypass.
-
Opaque proprietary filters do not interoperate.
-
Legacy labeling efforts depended too heavily on voluntary semantics without meaningful enforcement hooks.
-
Pure network blocking is often too coarse, too invasive, or too easy to evade.
-
Hard identity checks can be disproportionate, privacy-hostile, and risky to centralize.
AXEL takes a different approach.
It defines an interoperable framework for:
-
explicit labeling of age-restricted resources,
-
cryptographically verifiable policy publication,
-
privacy-preserving threshold proofs such as “18+” without unnecessary identity disclosure,
-
and layered enforcement profiles across service, device, and optional network environments.
AXEL is not a moral panic project. It is an engineering project for reducing ambiguity, improving interoperability, and making age-gating less ad hoc, less invasive, and more technically accountable.
AXEL is guided by the following principles:
If a resource is age-restricted, that fact should be published in a structured, machine-readable form.
A service often does not need to know who a user is.
It usually only needs to know whether the user satisfies a policy threshold such as 18+.
There is no one perfect enforcement point. AXEL supports enforcement at multiple layers:
-
service/application,
-
client/device,
-
and optionally managed network boundaries.
AXEL aims to minimize unnecessary disclosure and avoid turning age-gating into a general-purpose identity surveillance scheme.
AXEL is:
-
a policy publication format for age-restricted content,
-
a validation model for clients and enforcement tools,
-
an attestation profile for privacy-preserving proof of age eligibility,
-
a deployment framework for layered enforcement.
AXEL includes several protocol elements, including:
-
AXEL-STS — policy publication and transport/security requirements for age-restricted origins,
-
AXEL labels — structured age/category declarations,
-
attestation flows — proof that a client satisfies an age threshold,
-
enforcement profiles — service, device, and optional network policy behavior.
AXEL is not:
-
a claim that the network alone can perfectly determine the meaning of all content,
-
a demand for full legal identity disclosure for every access attempt,
-
a replacement for all moderation, classification, or legal compliance frameworks,
-
a promise that DNS and firewalls magically solve every age-gating problem.
AXEL does not assume that a single mechanism can solve classification, consent, jurisdiction, and user intent all at once.
Instead, it tries to define a sane, composable substrate.
At a high level, AXEL works like this:
-
A service publishes AXEL policy metadata indicating that some content or resources are age-restricted.
-
A client, browser extension, or enforcement intermediary discovers that policy.
-
The policy specifies the threshold or category requirements for access.
-
The client obtains or presents a privacy-preserving attestation satisfying the relevant threshold.
-
The origin validates the attestation and grants or denies access.
-
Optional device or managed-network tooling may consume the same metadata to apply local policy.
This separates three concerns that are too often muddled together:
-
labeling — what kind of restriction applies,
-
attestation — whether the user satisfies a threshold,
-
enforcement — where the decision is applied.
AXEL labels are machine-readable declarations describing restricted material.
Examples include:
-
age threshold:
16+,18+,21+ -
category: explicit sexual content, gambling, graphic violence, regulated commerce
-
scope: whole origin, path subtree, asset class, or protected endpoint
-
policy semantics: advisory, required for access, jurisdiction-conditioned
AXEL labels are designed to be explicit enough for automation while still being implementable by real systems.
AXEL-STS is the policy publication mechanism for AXEL-aware origins.
It allows an origin to publish:
-
whether AXEL enforcement is active,
-
which policy version applies,
-
which attestation profile is supported,
-
whether insecure downgrade paths are permitted,
-
cache lifetime and policy scope,
-
optional discovery endpoints.
AXEL-STS plays a role conceptually similar to transport-security policy publication: it makes enforcement expectations explicit and machine-consumable.
AXEL separates proof of eligibility from proof of identity.
The long-term direction is privacy-preserving attestation, including threshold proofs such as:
-
“the user is over 18”
-
“the user is over 16”
-
“the user satisfies jurisdiction-specific age threshold X”
without requiring the relying party to learn full identity attributes unless explicitly required by law or deployment profile.
AXEL is compatible with multiple attestation models, including:
-
zero-knowledge or selective-disclosure credential systems,
-
privacy-preserving token issuance flows,
-
wallet-backed verifiable credential profiles,
-
higher-assurance regulated deployments where stronger verification is required.
AXEL supports multiple enforcement profiles.
The origin or application validates AXEL attestation directly before granting access.
This is the primary and most robust deployment model.
A browser, app, operating system, parental-control tool, or extension consumes AXEL policy metadata and applies user- or administrator-defined policy locally.
A managed gateway, firewall, or resolver consumes AXEL metadata and applies coarse-grained policy where appropriate.
This profile is explicitly secondary. It is useful in some managed environments, but AXEL does not pretend that network-layer controls are always precise or sufficient on their own.
AXEL may use DNS as a discovery and policy distribution surface where appropriate.
This includes:
-
bootstrap discovery records,
-
policy advertisement,
-
optional deployment metadata,
-
experimental authorized-prefix hints for tightly controlled environments.
DNS support is part of the deployment story, not the entirety of the protocol.
AXEL does not assume that IP topology alone is a reliable semantic representation of content boundaries on the modern web.
AXEL is IPv6-aware and IPv6-friendly, but not IPv6-dogmatic.
IPv6 matters because it enables cleaner addressing models, simpler policy expression in some managed deployments, and future-facing infrastructure assumptions.
However, AXEL is fundamentally about policy publication and threshold enforcement, not about romanticizing one network layer.
The protocol should remain useful even when the most important enforcement decision happens at the service or device layer.
This repository contains a reference implementation of the AXEL model and surrounding tooling.
Current technology choices include:
-
ReScript — type-safe validator and policy handling
-
Deno — modern runtime and tooling
-
proven — formalized validation components in Idris2 where applicable
-
Zig FFI — C-compatible systems integration layer
The implementation is intended to demonstrate:
-
AXEL-STS parsing and validation
-
policy discovery
-
attestation flow integration points
-
deployment tooling for managed environments
-
reference firewall and policy-consumer integration
This repository aims to provide:
-
a readable protocol specification,
-
a reference validator,
-
deployment examples,
-
formalized validation logic where feasible,
-
integration guidance for downstream adopters.
It is both a research vehicle and an implementation scaffold.
Status: Draft / active design and reference implementation work
As of 2026-01-31:
-
✅ AXEL Protocol specification, draft baseline
-
✅ AXEL-STS validator in ReScript
-
✅ Initial deployment tooling and containerization
-
✅ Baseline security hardening work
-
⏳ Reference attestation service
-
⏳ Browser and client integration
-
⏳ Formal interoperability test vectors
-
⏳ Policy publication and discovery hardening
-
⏳ External review and standards alignment
AXEL should currently be understood as:
-
promising for experimentation,
-
useful for prototype deployments,
-
not yet a finished ecosystem standard.
AXEL is intentionally split into separable layers.
How that declaration is made available in a verifiable and machine-readable form.
AXEL is designed to improve assurance against:
-
trivial self-attestation bypass,
-
inconsistent or missing labeling,
-
silent downgrade to non-enforced policy,
-
ad hoc policy interpretation across clients,
-
unnecessary disclosure of user identity attributes.
AXEL does not claim to eliminate:
-
all evasion via VPNs or unmanaged devices,
-
misclassification by content publishers,
-
every jurisdictional ambiguity,
-
every abuse case in hostile or negligent deployments.
A serious protocol states what it cannot guarantee.
AXEL does not aim to be:
-
a universal internet censorship substrate,
-
a substitute for content classification policy,
-
a comprehensive identity platform,
-
a guarantee of legal compliance in every jurisdiction,
-
a magical network-only solution to human governance problems.
-
finalize AXEL label semantics
-
finalize AXEL-STS publication format
-
harden validator behavior and test vectors
-
publish example policies and fixtures
-
document threat model and security considerations
-
reference attestation service
-
browser extension / client integration
-
device-enforcement proof of concept
-
threshold-proof profile documentation
-
interoperability fixtures for relying parties
-
DNS helpers and policy generators
-
Terraform / Ansible deployment modules
-
containerized policy services
-
firewalld and managed-gateway integration
-
logging / audit guidance for privacy-preserving deployments
AXEL’s thesis is simple:
Age-gating works best when content restriction is explicit, policy is machine-readable, proof of eligibility is privacy-preserving, and enforcement can happen at more than one layer.
That is a narrower and more realistic claim than “the network will solve this.” It is also a much more interesting one.
Contributions are welcome, especially in the following areas:
-
protocol review
-
adversarial analysis
-
security and privacy critique
-
formalization work
-
interoperability testing
-
deployment ergonomics
-
accessibility and client UX for enforcement flows
Critical feedback is useful here. This repository is not trying to protect a fantasy from scrutiny; it is trying to refine a real design under pressure.
See the LICENSE file.
AXEL is a serious draft effort, not a finished standard.
Some parts are already implementable. Some parts are still better understood as research questions. That is normal.
The point of this repository is to make the idea concrete enough to test, criticize, simplify, and either harden into something real or discard with clarity.