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

        Anti-Squatting, Anti-Phishing and Plural Reputation Model
                    for the Internet 5.0 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 propose anti-abuse mechanisms for I5NS without creating a central
   censorship authority.

Abstract

   This document defines principles to reduce name squatting, typosquatting,
   Unicode homograph attacks, phishing, brand impersonation, compromised keys
   and suspicious locator changes in I5NS while preserving decentralization,
   plural reputation, contestability and absence of backdoors.

1. Core Principle

   Human-readable names are convenience aliases, not absolute property. The
   canonical root of trust is the cryptographic identity, accompanied by
   historical use, signed records, verifiable proofs and plural reputation.

2. Anti-Squatting

   I5TRUST-REQ-01: The system MUST NOT recognize absolute, perpetual and
   commercially alienable property over human-readable names as a protocol
   requirement.

   I5TRUST-REQ-02: Clients and reputation lists MAY downgrade names without
   proven use, without active content, without proof of control, without
   signing history or with evidence of speculative registration.

   I5TRUST-REQ-03: Transfer of a human-readable name MUST NOT automatically
   transfer reputation, history, trust or previous verifications.

   I5TRUST-REQ-04: Reputation SHOULD follow cryptographic identity and
   historical use, not merely the human-readable string.

3. Anti-Phishing

   I5TRUST-REQ-05: I5NS clients SHOULD detect visually confusable names,
   Unicode homograph attacks, character substitution, typosquatting and
   impersonation of brands or recognized identities.

   I5TRUST-REQ-06: I5NS clients SHOULD display stronger warnings when a new,
   low-reputation name is visually similar to a verified name, financial
   institution, public service, health service, critical platform or high-risk
   identity.

   I5TRUST-REQ-07: Sudden locator changes in high-reputation identities SHOULD
   trigger warnings and require additional verification.

4. Reputation Lists

   Reputation lists MUST be plural, signed, auditable, voluntary and
   contestable. No reputation list MUST be mandatory at the protocol level.

   Suggested types: Trust List, Warning List, Fraud List, Phishing List,
   Compromised Key List and Dispute List.

5. User Display

   Clients SHOULD display signals such as verified, recognized source,
   unverified source, disputed name, visually similar to known source,
   identity reported for phishing, compromised key and high risk.

6. Anti-Censorship Limits

   Anti-abuse mechanisms MUST NOT create a central censorship authority,
   global kill switch, backdoor, mandatory censorship list or mandatory civil
   identity registry.