HUMIA: A Website-First Protocol for Human-AI Cooperation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Web has a language for crawling. It needs a language for cooperation.¶

The Robots Exclusion Protocol (REP) [RFC9309] provides a widely deployed mechanism for crawlers to understand path-level crawling preferences. Modern AI systems, however, can interact with websites for materially different purposes, including assisting a user, retrieving information for a response, indexing information, bulk collection, or model training.¶

HUMIA provides a small, origin-level JSON document through which a website can state cooperation conditions for those interactions. The design is intentionally website-first: publication requires only a static JSON file, and no HUMIA account, registration, API, or server-side component is required.¶

This document defines HUMIA Protocol version 0.3 as an experimental protocol. It intentionally defines a small interoperable core. More advanced mechanisms such as authenticated agent identity, delegated authority, capability negotiation, enforcement, settlement, and signed receipts are outside the scope of this version.¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.¶

BCP 14 consists of RFC2119 and RFC8174; see [BCP14].¶

Publisher

The operator responsible for an HTTPS origin and its HUMIA policy.¶

Agent

An automated system that retrieves or uses Web resources, including AI-enabled systems acting independently or on behalf of a user.¶

HUMIA policy

The JSON representation retrieved from /.well-known/humia.json for an origin.¶

Canonical origin

The HTTPS origin identified by the identity.canonical member of the policy.¶

Usage purpose

A declared category describing why an agent intends to use public content.¶

3. Protocol Overview

A HUMIA-aware agent discovers the policy for an HTTPS origin by requesting:¶

https://example.com/.well-known/humia.json

If a valid policy is returned, the agent can use the policy to understand the publisher's declared cooperation policy.¶

A publisher MAY additionally include the following experimental discovery record in robots.txt:¶

<CODE BEGINS># HUMIA Protocol discovery (experimental)
Humia: https://example.com/.well-known/humia.json
<CODE ENDS>

The well-known URI is canonical. The Humia: record is only a discovery hint and is not required for HUMIA operation.¶

4. Well-Known URI

https://example.com/.well-known/humia.json

5. JSON Representation

The top-level representation is a JSON object. The following example is illustrative:¶

{
  "protocol": "HUMIA",
  "version": "0.3",
  "status": "draft",
  "identity": {
    "name": "Example Publisher",
    "canonical": "https://example.com/"
  },
  "access": {
    "public_content": "allow",
    "private_api": "deny"
  },
  "usage": {
    "user_assistance": "allow",
    "search_retrieval": "allow",
    "bulk_crawl": "deny",
    "training": "deny"
  },
  "attribution": {
    "required": true,
    "canonical_url": true
  },
  "reciprocity": {
    "usage_reporting": "requested"
  }
}

Unknown top-level members and unknown members inside defined objects MUST be ignored by agents unless a future HUMIA version defines otherwise. This permits compatible extension of the representation.¶

6. Required Members

7. Access Conditions

access is OPTIONAL. When present, it MUST be a JSON object.¶

public_content

Declares the publisher's HUMIA condition for publicly reachable content. Values are allow or deny.¶

private_api

Declares the publisher's HUMIA condition regarding use of private or non-public APIs. Values are allow or deny.¶

These values are declarative cooperation conditions. They do not bypass authentication, authorization, paywalls, network controls, or other technical restrictions.¶

8. Usage Conditions

usage is OPTIONAL. When present, it MUST be a JSON object.¶

This version defines the following usage purposes. Each value is allow or deny.¶

user_assistance

Retrieval or reading of public content for the purpose of answering or assisting a specific user request.¶

search_retrieval

Retrieval, indexing, or referencing of public content for search, discovery, retrieval, grounding, or source-backed responses.¶

bulk_crawl

High-volume or systematic collection of public content beyond targeted retrieval for a specific user request.¶

training

Use of retrieved content as training material for a machine-learning model, including pre-training or subsequent model training.¶

A publisher MAY omit a usage purpose. Omission means HUMIA makes no statement for that purpose. It MUST NOT be interpreted as allow or deny.¶

9. Attribution

attribution is OPTIONAL. When present, it MUST be a JSON object.¶

required

A boolean. When true, the publisher requests attribution when content is used in a context where attribution can reasonably be provided.¶

canonical_url

A boolean. When true, attribution SHOULD preserve or link to the canonical source URL where technically possible.¶

This document does not define an attribution rendering format.¶

10. Reciprocity

reciprocity is OPTIONAL. When present, it MUST be a JSON object.¶

usage_reporting

The string requested indicates that the publisher requests usage reporting when the agent supports such reporting.¶

Version 0.3 does not define a reporting transport, reporting endpoint, mandatory reporting behavior, compensation mechanism, or settlement protocol. requested is therefore an informational cooperation request, not an authorization requirement.¶

11. Relationship to robots.txt

HUMIA does not replace REP [RFC9309].¶

A crawler that is subject to REP MUST continue to evaluate and honor robots.txt independently of HUMIA. HUMIA does not grant permission to crawl a path that REP disallows.¶

Whether REP applies to an agent acting interactively on behalf of a user is outside the scope of this document.¶

Humia: https://example.com/.well-known/humia.json

12. Human-Readable Presentation

A publisher tool MAY present a plain-language explanation of the policy in addition to the machine-readable JSON. Such explanations are non-normative. In case of disagreement, the JSON representation is authoritative for HUMIA processing.¶

13. Security Considerations

HUMIA is a public policy mechanism and MUST NOT contain passwords, bearer tokens, API keys, private credentials, personal authentication material, or other secrets.¶

A HUMIA policy is not an access-control mechanism. Agents MUST NOT use an allow value to bypass authentication, authorization, network restrictions, payment requirements, or other controls.¶

Publishers should serve HUMIA over HTTPS to protect policy integrity in transit. This specification defines the protocol only for HTTPS origins.¶

Agents fetching HUMIA policies should apply normal protections against server-side request forgery, malicious redirects, oversized responses, resource exhaustion, and malicious JSON inputs. Cross-origin redirects are prohibited by this specification to reduce origin-confusion risks.¶

A malicious party that gains control of a publisher's origin can alter the HUMIA policy. HUMIA does not attempt to provide security beyond the security properties of HTTPS and control of the origin in version 0.3.¶

14. Privacy Considerations

Fetching a HUMIA policy can reveal to the publisher that an automated client is interested in the origin, just as fetching other public resources can.¶

A HUMIA request does not require an agent to disclose an end user's identity. Implementations SHOULD NOT add user-identifying information to HUMIA discovery requests unless another protocol or explicit user authorization requires it.¶

Publishers SHOULD avoid placing personal data in the HUMIA policy. The policy is intended to be public and broadly cacheable.¶

15. Versioning and Extensibility

The version member identifies the HUMIA protocol version used by the representation.¶

Version 0.3 intentionally defines a small core. Future versions may define additional objects or members, including agent identity, delegated authority, capabilities, interaction mechanisms, verification, enforcement, and richer reciprocity.¶

Unknown members MUST be ignored as specified in Section 5. New semantics that would change the meaning of existing members require a new HUMIA version.¶

16. IANA Considerations

This document requests registration in the "Well-Known URIs" registry established by [RFC8615].¶

URI suffix

humia.json¶

Change controller

HUMIA Protocol¶

Specification document

This document.¶

Status

provisional¶

Related information

https://humiaprotocol.org/¶

The registered resource is a JSON representation served over HTTPS with media type application/json.¶

17. Implementation Status

This section is non-normative and may be removed before publication as an RFC.¶

As of August 2026, a public experimental implementation is available at https://humiaprotocol.org/.well-known/humia.json, together with a browser-based policy generator that produces a robots.txt discovery snippet and a HUMIA JSON policy without requiring an account or backend service.¶

Additional pilot deployments are being used to evaluate deployment ergonomics and policy semantics. No claim is made that major AI providers currently implement or honor HUMIA.¶

18. Acknowledgements

The author thanks the Web and Internet standards communities whose work on HTTP, JSON, well-known URIs, and the Robots Exclusion Protocol makes this experiment possible.¶

Appendix A. Change Log

Author's Address