Consent-Aware HTTP: Declarative Boundaries for AI Usage

Table of Contents

• 1. Overview
  • 1.1. HTTP Status Code 430: Consent Required
  • 1.2. AI Boundary Declaration Protocol (AIBDP)
• 2. Quick Links
• 3. Why This Matters
• 4. Getting Started
  • 4.1. Quick Implementation (4 Steps)
  • 4.2. Comprehensive Documentation
• 5. Ethics and Governance
  • 5.1. Core Values
  • 5.2. Philosophical Foundations
• 6. Contributing
  • 6.1. Contribution Types
  • 6.2. Tri-Perimeter Contribution Framework (TPCF)
• 7. Licensing
  • 7.1. License Options
  • 7.2. SPDX Headers
  • 7.3. License Files
• 8. Project Information
  • 8.1. Built By
  • 8.2. Community
  • 8.3. Funding
  • 8.4. Standards Track
• 9. Repository Structure
• 10. Technical Specifications
  • 10.1. HTTP 430 Response Format
  • 10.2. AIBDP Manifest Location
  • 10.3. Reference Implementations
• 11. Validation & Testing
  • 11.1. Quick Validation
  • 11.2. Development Environment
  • 11.3. Testing AIBDP Implementation
• 12. Security Considerations
• 13. Acknowledgments
  • 13.1. Theoretical Foundations
  • 13.2. Technical Influences
  • 13.3. Community
• 14. Appendices
  • 14.1. Appendix A: Glossary
  • 14.2. Appendix B: Related Standards
  • 14.3. Appendix C: Compliance Checklist

You have not the freedom of the house.

— Virginia Woolf
The Waves

This repository hosts formal proposals, implementation materials, and ethical guidance for consent-aware architecture in the age of generative systems. At its heart are two interlinked Internet-Drafts designed to enforce procedural refusals when AI usage boundaries are unmet or ignored.

1. Overview

1.1. HTTP Status Code 430: Consent Required

🚦 draft-jewell-http-430-consent-required

Defines HTTP Status Code 430 (Consent Required), enabling servers to reject access when AI-specific consent declarations are invalid, missing, or violated. It empowers refusal not as punishment, but as principled perimeter enforcement.

Status: Internet-Draft 00 (IETF submission ready)
Specification: XML | Text | HTML

1.2. AI Boundary Declaration Protocol (AIBDP)

🧭 draft-jewell-aibdp

Introduces the AI Boundary Declaration Protocol (AIBDP) - a machine-readable manifest (/.well-known/aibdp.json) for signaling what forms of AI engagement are permitted. It formalizes intent, fosters transparency, and restores agency to originators.

Status: Internet-Draft 00 (IETF submission ready)
Specification: XML | Text | HTML

Important

Together, these protocols establish declarative boundaries that resist unauthorized training, indexing, or generative reuse - compatible with federated infrastructure and public web publishing alike.

2. Quick Links

Resource	Description	Format
HTTP 430 Draft	Status code specification	RFC XML
AIBDP Draft	Manifest protocol specification	RFC XML
Developer Guide	Implementation guidance	Markdown
Philosophical Overview	Cultural and ethical context	Markdown
Quick Start	Templates and examples	Markdown
FAQ	60+ questions answered	Markdown
Reference Implementations	Node.js, Python, Rust	Code
Server Configs	nginx, Apache, Caddy, Cloudflare, etc.	Markdown

3. Why This Matters

AI systems often ingest, embed, and regenerate content without consent - erasing boundary, authorship, and intent.

These protocols restore procedural clarity to web interactions, allowing creators to:

• ✅ Refuse generative reuse without legal escalation

• ✅ Declare acceptable AI uses in a standardized way

• ✅ Signal denial with structured protocol, not vague error codes

• ✅ Collaborate on infrastructure that respects ethical constraints

Boundary is where meaning begins.

— bell hooks

4. Getting Started

4.1. Quick Implementation (4 Steps)

1. Create AIBDP Manifest
   Add /.well-known/aibdp.json with your declared boundaries

   {
     "aibdp_version": "0.2",
     "contact": "mailto:[email protected]",
     "policies": {
       "training": { "status": "refused" },
       "indexing": { "status": "allowed" }
     }
   }

2. Configure Server
   Update server logic to respond with HTTP 430 when violations occur

   location = /.well-known/aibdp.json {
       add_header Content-Type application/aibdp+json;
   }

3. Use Templates
   See start-here.md for templates, examples, and server configs

4. Join Community
   Engage in IndieWeb, Fediverse, or IETF circles to promote shared adoption

Tip	These standards can be implemented independently of platform, license, or scale - ideal for personal blogs, union archives, CDN layers, or federated identity services.

4.2. Comprehensive Documentation

Technical Guide	Implementation details for developers
Explainer	Architectural overview and philosophy
Ethics	Cultural and theoretical foundations
Governance	Organizational implications
Conformance	Implementation requirements
References	Citations and influences
Manifest Examples	12 real-world scenarios
Server Configs	8 platform guides

5. Ethics and Governance

This project draws on traditions of ethical journalism, federated systems, and authorship dignity.

5.1. Core Values

Declarative refusal as a form of care
Boundary as the place where meaning begins
Transparent infrastructure over implied permissions
Sanctuary work as both cultural and procedural

5.2. Philosophical Foundations

• bell hooks: Boundary-setting as dignity and care

• Virginia Woolf: Architectural refusal as self-determination

• Journalism Ethics: Right to decline co-option (NUJ, SPJ)

• IndieWeb: Self-sovereignty and federated control

Note	Explore more in ethics.md and governance.md.

6. Contributing

We welcome developers, ethicists, teachers, organizers, and critics.

See CONTRIBUTING.md for guidelines.

6.1. Contribution Types

• 📝 Draft improvements - Technical feedback on Internet-Drafts

• 🔧 Schema extensions - AIBDP manifest enhancements

• 📚 Educational modules - Teaching materials and tutorials

• ✍️ Narrative essays - Ethical and cultural perspectives

• 🌍 Adoption stories - Implementation case studies

• 🤝 Outreach coordination - Community engagement

6.2. Tri-Perimeter Contribution Framework (TPCF)

This project uses the TPCF governance model:

Perimeter	Access Level	Description
Perimeter 1 (Core)	Maintainers only	Internet-Draft authoring, protocol design decisions, security-critical changes
Perimeter 2 (Expert)	Trusted contributors	Reference implementations, comprehensive documentation, schema validation
Perimeter 3 (Community)	Open contribution	Examples, translations, outreach materials, issue reporting

See GOVERNANCE.adoc for complete decision-making framework.

7. Licensing

Dual-licensed for maximum flexibility with ethical encouragement

7.1. License Options

This project offers three licensing options:

License	Applies To	SPDX Identifier
MIT (Permissive)	Code, specifications, reference implementations	MIT
GPL-3.0-or-later (Copyleft)	Code, specifications (alternative to MIT)	GPL-3.0-or-later
CC BY-SA 4.0 (ShareAlike)	Documentation, narrative, educational materials	CC-BY-SA-4.0

Important

Palimpsest License (Philosophically Encouraged) We philosophically encourage dual-licensing under the Palimpsest License v0.8 alongside MIT or GPL-3.0+. Why Palimpsest? Preserves attribution through edit history Embeds ethical provenance in creative work Supports solidarity economics Aligns with consent-aware philosophy Learn more: https://palimpsest.license Full text: LICENSE-PALIMPSEST.txt Palimpsest is optional but reflects our values. Choose the license that works for you.

7.2. SPDX Headers

All source files include SPDX license identifiers:

// SPDX-License-Identifier: MIT OR GPL-3.0-or-later
// SPDX-FileCopyrightText: 2025 Jonathan D.A. Jewell

Run just audit-licence to verify compliance.

7.3. License Files

• LICENSE.txt - Primary license (MIT)

• LICENSE-MIT.txt - MIT full text

• LICENSE-GPL-3.0.txt - GPL-3.0 full text

• LICENSE-PALIMPSEST.txt - Palimpsest v0.8

• LICENSE-CC-BY-SA-4.0.txt - Creative Commons (docs)

8. Project Information

8.1. Built By

Jonathan D.A. Jewell
NEC PRC Representative · NUJ Ethics Council · AI & Data Working Group (Convenor)

Contact: [email protected]
GitHub: @Hyperpolymath

8.2. Community

GitHub	https://github.com/Hyperpolymath/consent-aware-http
Discussions	https://github.com/Hyperpolymath/consent-aware-http/discussions
Issues	https://github.com/Hyperpolymath/consent-aware-http/issues
Email	[email protected]

8.3. Funding

This project is sustained through:

• Individual donations (FUNDING.yml)

• Solidarity economics framework

• Volunteer contributions

See FUNDING.yml for support options.

8.4. Standards Track

Document	Status	Target
draft-jewell-http-430-consent-required	Internet-Draft 00	IETF HTTP Working Group
draft-jewell-aibdp	Internet-Draft 00	IETF or W3C
JSON Schema (AIBDP)	v0.2 stable	Community adoption

9. Repository Structure

consent-aware-http/
├── draft-jewell-http-430-consent-required-00.xml  # HTTP 430 spec
├── drafts/
│   └── draft-jewell-aibdp-00.xml                  # AIBDP spec
├── schemas/
│   └── aibdp-schema-v0.2.json                     # JSON Schema
├── examples/
│   ├── reference-implementations/
│   │   ├── nodejs/                                # Express middleware
│   │   ├── python/                                # Flask middleware
│   │   └── rust/                                  # (planned)
│   └── manifest-scenarios/                        # 12 real-world examples
├── docs/                                          # Comprehensive guides
├── assets/                                        # Badges, templates
├── .well-known/                                   # RFC 9116 + AIBDP
├── scripts/                                       # Build tools
└── .github/                                       # Community docs

See directory-structure.md for detailed layout.

10. Technical Specifications

10.1. HTTP 430 Response Format

HTTP/1.1 430 Consent Required
Content-Type: application/json
Link: <https://example.org/.well-known/aibdp.json>; rel="blocked-by-consent"
Retry-After: 86400

{
  "error": "AI usage boundaries declared in AIBDP manifest not satisfied",
  "manifest": "https://example.org/.well-known/aibdp.json",
  "violated_policy": "training",
  "policy_status": "refused",
  "contact": "mailto:[email protected]"
}

10.2. AIBDP Manifest Location

Location	/.well-known/aibdp.json (RFC 8615 compliant)
Format	JSON with declared permissions/prohibitions
Signature	Optional COSE (RFC 9052) cryptographic verification
Caching	Configured via expires field (recommended: 30-90 days)

10.3. Reference Implementations

Language	Framework	Status	Lines
JavaScript/Node.js	Express	✅ Production-ready	300+
Python	Flask	✅ Production-ready	400+
Rust	Axum (planned)	🚧 Planned	TBD

11. Validation & Testing

11.1. Quick Validation

# Validate all manifests and specs
just validate

# Check RSR compliance
just check-rsr

# Run tests
just test

# Build Internet-Drafts
just build-drafts

11.2. Development Environment

Using Nix flakes (reproducible builds):

# Enter dev shell with all tools
nix develop

# Or run specific commands
nix run .#validate
nix run .#check-rsr

11.3. Testing AIBDP Implementation

# Test manifest accessibility
curl https://example.org/.well-known/aibdp.json

# Test AI bot blocking (should return 430)
curl https://example.org/articles/ -H "User-Agent: GPTBot/1.0"

# Test normal access (should return 200)
curl https://example.org/ -H "User-Agent: Mozilla/5.0"

12. Security Considerations

Warning

AIBDP is a declarative protocol, not a technical enforcement mechanism: Non-compliant AI systems may ignore manifests Detection requires active monitoring Legal/reputational consequences provide primary enforcement HTTPS + COSE signatures recommended for high-value content

See security-analysis.md for comprehensive threat model.

13. Acknowledgments

13.1. Theoretical Foundations

• bell hooks - Cultural criticism, boundary theory

• Virginia Woolf - Architecture of refusal

• National Union of Journalists (NUJ) - Ethics framework

• Society of Professional Journalists (SPJ) - Code of ethics

13.2. Technical Influences

• RFC 7231 - HTTP/1.1 Semantics

• RFC 8615 - Well-Known URIs

• RFC 9052 - COSE (Cryptographic signatures)

• RFC 9116 - security.txt

• IndieWeb - Federated publishing standards

13.3. Community

• IndieWeb participants

• Federated web advocates

• Ethical AI practitioners

• IETF working groups

• Journalism ethics communities

The act of naming is the act of creating boundaries. And boundary is where meaning begins.

— bell hooks

Without refusal, permission is meaningless.

14. Appendices

14.1. Appendix A: Glossary

AIBDP

AI Boundary Declaration Protocol - manifest format for declaring AI usage boundaries

HTTP 430

Consent Required - proposed HTTP status code for consent violations

Manifest

JSON document at /.well-known/aibdp.json declaring AI usage policies

COSE

CBOR Object Signing and Encryption (RFC 9052)

TPCF

Tri-Perimeter Contribution Framework - graduated trust model

14.2. Appendix B: Related Standards

• RFC 2119 - Key words for RFCs (MUST, SHOULD, etc.)

• RFC 7231 - HTTP/1.1 Semantics

• RFC 7725 - HTTP 451 (Legal Obstacles)

• RFC 8259 - JSON format

• RFC 8615 - Well-Known URIs

• RFC 9052 - COSE

• RFC 9116 - security.txt

14.3. Appendix C: Compliance Checklist

See RSR-COMPLIANCE.md for Rhodium Standard Repository compliance status.

---

Repository: https://github.com/Hyperpolymath/consent-aware-http
Website: https://consent-aware-http.org
License: MIT OR GPL-3.0-or-later + CC BY-SA 4.0 (Palimpsest encouraged)
Version: 0.2.0
Last Updated: 2025-07-20