HUMIA Protocol v0.3

1. Abstract

HUMIA defines a machine-readable policy document through which an origin can express identity, resource access, intended AI usage, attribution preferences and reciprocity preferences. The protocol is designed to complement existing Web mechanisms rather than replace them.

2. Scope and terminology

Publisher means the operator responsible for the Web origin. Agent means automated software acting autonomously or on behalf of a user. Policy means the JSON representation served from the HUMIA well-known location.

HUMIA distinguishes access (which resources may be retrieved) from usage (what an agent may do with retrieved content).

3. Discovery

The canonical candidate location is:

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

An origin MAY additionally advertise this location in /robots.txt using an experimental record:

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

The Humia: record is optional. It MUST NOT change the meaning of Allow or Disallow rules. Agents that do not understand it may ignore it.

4. Retrieval and representation

• Clients retrieve the policy using HTTP GET.
• HTTPS is the preferred scheme for public deployment.
• The representation is UTF-8 JSON and SHOULD be served as application/json.
• The policy applies to the origin that serves it unless a future specification explicitly defines narrower scope.

5. Core document

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

6. Usage purposes

7. Attribution and reciprocity

Attribution expresses whether preservation of the canonical source is requested as a condition of cooperation. Reciprocity is broader than payment: it may include reporting, structured access, service credits, direct agreements or other mutually accepted exchanges in later extensions.

8. Fallback behavior

Absence, invalidity or an unsupported HUMIA version MUST NOT be interpreted as additional permission. Existing Web controls, applicable law, contracts and technical access controls continue to apply independently.

9. Security considerations

A HUMIA document is public metadata, not an authentication or authorization mechanism by itself. Publishers MUST NOT place secrets, credentials or non-public endpoint details in it. A policy declaration cannot replace server-side access controls. Clients should apply normal limits to JSON size, redirects and parsing.

10. Privacy considerations

The core policy does not require personal data. Agent identity, event reporting and analytics are separate capabilities and should minimize personal data and follow applicable privacy law.

11. Versioning

Clients should treat unsupported major policy semantics conservatively. This v0.3 document is a candidate draft and may change before a stable 1.0 specification.

12. IANA considerations

This candidate is being prepared for a possible provisional registration request in the IANA Well-Known URIs registry. No registration is claimed by this document.

13. References

• RFC 8615 — Well-Known Uniform Resource Identifiers (URIs)
• RFC 9309 — Robots Exclusion Protocol

14. Change control and feedback

HUMIA Protocol is currently an experimental open project. Change-control details and a public feedback process will be formalized before an IANA registration request.