I5NS-DRAFT-00 — Internet 5.0 Naming System

Internet 5.0 Initiative                                      A. F. Rodrigues
Request for Comments: I5NS-DRAFT-00                         Independent
Category: Informational                                      27 May 2026

              Internet 5.0 Naming System (I5NS)
       A Cryptographic, Decentralized and Multi-Locator Naming System

Status of This Memo

   This document is an independent informational draft inspired by the
   Request for Comments format. It is NOT an official IETF RFC. Its purpose is
   to specify, at a conceptual level, a naming system for Internet 5.0.

Abstract

   I5NS is a naming system based on cryptographic identity, multiple signed
   locators, distributed publication and transparency logs. I5NS does not
   necessarily replace traditional DNS, but reduces dependence on a single
   root, a single registrar, a single resolver or a single access path.

1. Definition

   Verifiable cryptographic identity, for Internet 5.0 purposes, is an
   identifier derived from a public key, capable of signing records, names,
   routes, content and updates, without requiring mandatory linkage to civil
   identity, state registry, central authority or single registrar.

   Verifiability proves cryptographic control and continuity of authorship,
   not compulsory civil identification.

2. Name Types

   1. Canonical cryptographic name, derived from a public key.
      Example: i5id:ed25519:z6Mkp...

   2. Human-friendly name, associated with a cryptographic identity by means
      of a signed record.
      Example: internet5.i5

   The canonical name is the technical root of trust. The human name is a
   convenience alias subject to reputation, proof of use and possible dispute.

3. Normative Requirements

   I5NS-REQ-01: An I5 domain MUST be associated with a cryptographic identity.

   I5NS-REQ-02: An I5 domain MUST have a record signed by the owner key or by
   authorized recovery keys.

   I5NS-REQ-03: An I5 domain SHOULD allow multiple locators, including HTTPS,
   onion services, IPFS, mirrors, relays and caches.

   I5NS-REQ-04: An I5 domain MUST support key rotation and revocation.

   I5NS-REQ-05: An I5 domain MUST NOT depend on a single central authority
   capable of globally removing names by political decision.

   I5NS-REQ-06: I5NS clients SHOULD consult multiple registration sources,
   including transparency logs, distributed records, caches and configurable
   trust sources.

   I5NS-REQ-07: Human-name conflicts SHOULD be handled through transparency,
   reputation, temporal proof, proof of control and user display, and not
   through automatic global censorship.

4. Minimal I5NS Record

   A minimal record should contain claimed name, canonical cryptographic
   identifier, public key, locators, creation date, validity, recovery policy
   and signature.

5. Recovery

   I5NS records SHOULD support m-of-n recovery, allowing replacement of the
   primary key or revocation through joint signatures of recovery keys.

6. Distributed Publication

   I5NS records MAY be published through multiple channels, including
   .well-known files in traditional domains, DNS TXT, IPFS, public
   repositories, transparency logs, distributed caches and independent mirrors.

7. Resolution Privacy

   I5NS clients SHOULD reduce interest leakage through local cache, batched
   queries, multiple resolvers, oblivious queries, privacy networks, traffic
   padding or other appropriate mechanisms.

8. Anti-Bottleneck Considerations

   I5NS MUST NOT require global civil registration, mandatory KYC, a single
   approval authority, a global list of authorized identities or a single
   entity capable of revoking identities. A person MAY hold multiple
   contextual identities; public-content readers SHOULD be able to access
   without persistent identity.