The human and org URI Schemes

• Version: 0.1 — Draft for public review
• Date: 2026-08-15
• Author: Amod Dange
• Provenance: Originally authored by Amod Dange, 2026. This line is intended to survive subsequent revision: when stewardship transfers to an independent standards body and the document acquires editors, the original authorship remains part of the record.
• Status: Draft — not suitable for production use (§11.1). Published for review and to serve as the reference for provisional IANA registration of the human and org URI schemes under RFC 7595. Intended to be transferred to the stewardship of the Human Compact Consortium upon its formation, and to be revised toward a stable specification suitable for a request to promote both schemes to permanent status.
• Canonical location: https://humancompact.org/spec/human-uri-scheme/
• License: CC BY 4.0 — free to share, republish, translate, and adapt with attribution. Implementing this specification requires no permission and no royalty — see §14.

Abstract

This document defines two Uniform Resource Identifier (URI) schemes, human and org, which identify verified entities rather than network locations. A human URI identifies a natural person verified as a unique living human; an org URI identifies an organization whose control resolves to accountable natural persons. Devices — including embodied machines such as humanoid robots — and software agents are not given a scheme of their own: being always delegated, they are identified under the scheme of the human or organization accountable for them.

The schemes are designed for an overlay protocol in which identity is separated from location, mutual authentication is mandatory, contact with a person requires that person’s consent, and every consequential action carries a chain of authority terminating in an accountable human.

1. Introduction

1.1 Motivation

The Internet Protocol addresses machines at locations. It has no native representation of who is acting, whether they are a person, or who is accountable for a machine’s behavior. Identity, authentication, and authorization were each added later and outside the addressing layer — DNS, TLS and the certificate-authority system, passwords, OAuth, and various bot-detection heuristics — with the result that no widely deployed identifier answers the questions that now matter most: is this a person, is this a unique person, and if this is a machine, which person answers for it?

Embodiment sharpens those questions from fraud to physical safety: a humanoid robot on a public street is a machine whose accountability must be verifiable by anyone standing next to it — that a valid, unique, unrevoked human answers for it, never which human (§3.5). Synthetic media sharpens them just as hard in the other direction: when any face and any voice can be generated, is this really them? stops being answerable by inspection, and must become a question the identifier answers — does this carry their authority? (§3.6).

These questions were dormant for as long as the actors on the network were people and the machines people directly operated. They are urgent now that software acts on its own initiative, at scale, and can present convincingly as a person.

These schemes make that the property of the identifier itself.

1.2 Design principles

1. Identity is not location. An identifier denotes an entity; resolution maps it to whatever endpoints that entity currently uses.
2. Personhood is scarce. A human identifier is obtainable only by a party that can prove it is a unique living human. This is enforced cryptographically, not by policy.
3. No orphan machines. Every non-human entity carries a verifiable chain to an accountable human or organization.
4. Verification without surveillance. Verification yields the asserted property and nothing else. No verifier, resolver, or operator learns more than the property proved, and a natural person is never required to reveal which entity they are in order to be verified. Identifiers used in different contexts are unlinkable by construction, and can be associated only by the entity that holds them (§8.3).
5. Consent precedes contact. Dereferencing an identifier can never, by itself, deliver content to a person or cause an effect at the target.
6. Overlay, not replacement. These schemes run over the existing Internet and require no change to it.

7. The privacy default follows the accountability class. A human is private by default; an organization is public by default; a machine acting among humans is identifiable by default. The asymmetry is deliberate: disclosure obligations attach to the capacity to be accountable, not uniformly (§3.5, §10.1, §10.2). It follows that roles others depend upon — operating a resolver, issuing identifiers — are held by organizations rather than by natural persons (§6.1).

8. Reach is pulled, not pushed. Today an address grants access to whoever holds it: anyone with a person’s email address, phone number, or handle can put something in front of them, and the recipient can object only afterward, only to that sender, and only after the harm. These schemes reverse it. An identifier delivers nothing (§5.3). Asking about someone who has not permitted you fails, without revealing that they exist (§6.5). Nothing lists or counts the entities in the system, and no operation is a search: resolution answers about a reference the querier already holds, and hands back only what the entity bound to it (§6.2, §7). What a counterparty sees is what the entity allowed, in that context alone — and when the entity withdraws that, the identifier it held stops working, with no successor and no way to tell one exists (§10.4). Nothing about a person is broadcast, and no operation publishes one. The two deliberate exceptions prove the rule rather than qualify it: an organization is public by default because accountability it cannot be checked against is not accountability (§10.2), and a machine among humans broadcasts that someone answers for it, never who (§3.5.3). Both disclose an accountability class; neither discloses a person. Everything a counterparty knows about an entity, it knows because that entity permitted it: reach is granted, never assumed.

1.3 Relationship to other work

These schemes build on, and do not replace, W3C Decentralized Identifiers (DIDs) and Verifiable Credentials. A single entity may be described by DID documents under several DID methods; the schemes defined here are method-agnostic by requirement (§6.4). The identity/locator separation follows the tradition of the IETF Host Identity Protocol, generalized from hosts to typed, human-anchored entities.

These schemes address identity and accountability only. What may be done at an identified entity — the vocabulary of actions, the shapes of data exchanged, the capabilities a device offers — belongs to capability and type systems layered above, the space occupied by device-capability registries, tool-contract schemas, and vocabulary registries. This document deliberately specifies none of it (§4.8), and is designed to be the layer such systems rest on rather than a competitor to any of them.

1.4 Scope of this document

This document specifies identifier syntax, semantics, resolution, and comparison, together with security, privacy, and IANA considerations. The session protocol, the action and authority model (including representation grants), the credential and attestation formats, and the physical identification exchange referenced here are outside the scope of this document, and are described here only to the extent needed to define what these identifiers mean.

2. Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174.

Entity — anything that can be identified by these schemes: a human, an organization, a device, or a software agent.

Context — a bounded domain of participation within which an entity holds identifiers and sets its own visibility and reachability: an application, a service, a deployment, or any other setting a party joins as itself. An entity participates in as many as it chooses, each separate from every other. A context is not a counterparty: one context may hold many, which is why a setting may govern a single counterparty or a whole context (§10.4).

Root entity — an entity that can be an ultimate terminus of accountability: a verified human, or an organization controlled by verified humans. Only root entities have schemes.

Enrollment — the act by which a root entity becomes a participant, producing a single commitment that is unique to that entity and is not an identifier: it never appears in a URI, is never resolved, and plays no part in any interaction: no counterparty receives it, and it is disclosed to no party but the one that records it. Only root entities enroll. A root entity’s identifiers (§4) are derived beneath its enrollment and are mutually unlinkable (§10.3); properties scoped to enrollment rather than to an identifier — uniqueness, and any limit or exclusion that must survive a change of identifier — therefore hold across every identifier that entity uses, without any of those identifiers being linkable to one another.

Personhood proof — evidence, verifiable without revealing which entity presented it, that the presenting party is a unique living human.

Delegated entity — an entity that can never be an accountability terminus: a device or software agent. A delegated entity is valid only while it carries a verifiable anchor chain to exactly one root entity. It does not enroll: a root entity is constituted by enrollment, a delegated entity by its chain.

Anchor chain — a chain of signed attestations binding a delegated entity to a root entity.

Authority chain — a sequence of signed grants by which one entity confers on another the authority to act: each grant scoped, time-bounded, attenuable, and revocable, and the whole terminating in an accountable root entity (§5.4). Distinct from an anchor chain, which establishes who answers for a delegated entity; an authority chain establishes what it may do.

Attestation — a signed statement by a party about something it is positioned to know. Two uses appear in this document and neither implies the other: the attestations composing an anchor chain bind a delegated entity to a root, establishing who answers for it; an integrity attestation is a device’s statement about its own state (§9.10), establishing that it is sound.

Embodied entity — a delegated entity capable of physical action in space shared with humans: a robot, a vehicle, a drone. Embodiment is a property of a device, not a new entity type.

Humanoid — an embodied device whose form or presentation is anthropomorphic. A humanoid is a device, and carries the additional obligations of §3.5.

Digital twin — a software agent authorized by its principal, through a scoped representation grant, to present the principal’s likeness, voice, or name in interaction (§3.6). A digital twin is a delegated entity; the likeness does not change its type.

Identifier — the opaque, cryptographically derived value that identifies an entity. A URI carries one either directly, in its encoded form, or by way of a label that resolves to it (§4.2, §6.2).

Pairwise identifier — an identifier distinct to a single counterparty. An entity’s identifiers are pairwise by default: one per counterparty, in each context in which the entity participates, derivable by that entity and unlinkable by every other party, the implementation included (§10.3).

Label identifier — the single identifier a label denotes (§10.6). It is scoped to a context rather than to a counterparty, because a label is resolved by parties with whom no pair exists — an org label by anyone at all (§10.2, §10.3).

Entity reference — the part of a human or org URI that says which entity is meant, standing immediately after :// and before any path: either an encoded identifier or a label (§4).

Label — the human-readable form of an entity reference (§4): a name and a category, together with a jurisdiction where present and, where the holder has taken one, a full-length cryptographic discriminator (§4.6). A label is claimable only by proving entitlement to each component (§6.3), is not unique — two entitled entities may hold the same one (§4.6) — and is the only part of a reference that can be correlated (§10.5). A label is not a name — it carries one, alongside a category and, where present, a jurisdiction and a discriminator; sameness of label is never sameness of entity (§8.3).

Verification material — the cryptographic material by which an entity’s claims are checked: its current public keys, the credentials bound to them, and the assurance metadata describing what those credentials establish.

Rotation record — a signed, append-only record issued by an entity, each entry of which attests that specified verification material of that entity is superseded by specified successor material. An org entity publishes it; a human entity issues it to each counterparty individually and never publishes it (§10.4). Its format is not specified here; what this document requires of it is stated in §9.4.

Presence assertion — evidence that an entity is party to an interaction at the moment of that interaction: an act the entity performs live, cryptographically bound to the session or action it accompanies. Unlike a credential, which is issued in advance and presented later, a presence assertion cannot be produced ahead of time or reused (§3.6.3, §9.10).

Resolver — a service that maps an entity reference to verification material and delivery endpoints.

3. The entity model

3.1 Two schemes, because there are two kinds of accountability

The scheme is an accountability declaration, and it declares a class rather than an occupant. human:// asserts that whatever it addresses is a natural person, and that the natural person is where accountability terminates. org:// asserts that a legal person is addressed and that its control resolves to accountable natural persons. Neither says which entity: a reference may denote several (§4.6), and the assertion holds of each of them.

Consequently:

• An organization MUST NOT be identified by a human URI, and a natural person MUST NOT be identified by an org URI. Conflating them destroys the guarantee the scheme exists to make. The rule is enforced where it can be — at issuance, against the evidence §3.2 requires for each class.
• A delegated entity (device, software agent) MUST be identified under the scheme of its root entity: a device owned by a person uses human://; a device operated by an organization uses org://. This includes humanoids and every other embodied machine (§3.5). The scheme therefore discloses one fact about the root — whether it is a person or an organization — and that is deliberate: §3.5 requires a bystander to learn that a machine answers to someone accountable. It is also the whole of what a delegated identifier discloses about its root, since §10.7 forbids the identifier or its chain from yielding anything further.
• The scheme follows legal personality, not commercial activity. Where a natural person trades, contracts, or practises without a distinct legal person existing alongside them — a freelancer, a registered trade name, a sole proprietorship, an unincorporated association — accountability terminates in that person, the reference is human://, and the trade is expressed as a category (§4.4). Where a legal person exists that can be bound and sued in its own name, including a single-member company whose sole member is the person who runs it, the reference is org:// and that person is its authorized representative. Registration is not the test; what the registration evidences is.
• Accountability can terminate in only two places — in a natural person, or in a legal person that reduces to natural persons. Nothing else can hold it: a device, an agent, or a machine of any sophistication answers to whoever deployed it. That is why there are two schemes and why there will not be a third. New entity categories are expressed within the syntax (§4.4), never by minting new schemes.

3.2 What makes an identifier valid

Two kinds of requirement appear here, and the difference decides how each is established. What an identifier must be — a valid anchor chain, sufficient collision resistance — a verifier checks for itself, from what it is presented. What issuance must have guaranteed — a personhood proof, deduplication, the absence of a retained correspondence — no verifier can inspect: it is a claim about what the issuer did, and about what it did not keep. The second kind is why §3.3 states its conditions as properties of an implementation rather than of an identifier, and why each arrives with a stated evidence requirement rather than a promise. A requirement that cannot be checked and is not evidenced is an undertaking, and §3.3 does not accept undertakings.

A human identifier MUST be issued only against a personhood proof establishing that the holder is a unique living human, deduplicated against all other holders under the same deduplication method — which scopes the claim and is the whole of what it asserts (§3.3). A conforming issuance process MUST NOT leave any party to that process able to correlate the resulting identifier with any other record of that person. Where verification of personhood and issuance of the identifier are performed by different parties, the requirement binds each of them and their combination: the correspondence MUST NOT be derivable from their records taken together, nor become derivable should they later merge, share, or be compelled to produce what they hold.

An org identifier MUST be issued only against evidence that the organization exists as a legal person — in an authoritative public register that establishes legal personality rather than merely recording a name (§3.1) — together with an attestation by an authorized representative who is themself identified by a human identifier. That identifier binds the attestation and is disclosed to the issuer alone: it MUST NOT be published, and MUST NOT be resolvable from the organization’s reference (§4.4, §10.1). Accountability for an organization runs to the organization, never to the individual who signed for it — a specification that exposed the signer by construction would make accountability a hazard to the accountable.

Each of a delegated entity’s identifiers MUST carry an anchor chain to exactly one root entity, verifiable from what is presented (§5.4). An identifier without a valid anchor chain is invalid, not merely untrusted, and conforming implementations MUST reject it.

Every identifier, of whatever entity type, MUST provide at least 128 bits of effective collision and second-preimage resistance, and an implementation MUST NOT issue an identifier whose derivation yields less. The grammar’s minimum encoded length is that requirement written into the syntax: 52 base32 characters carry 260 bits, and 128-bit collision resistance requires at least 256 (§4.1). The maximum is the permissive bound — it accommodates multicodec prefixes and future encodings, and relaxes nothing. An identifier that a second party can feasibly duplicate or target is not an identity, and no property of this specification survives its loss.

3.3 Conditions on conforming implementations

The scheme’s guarantees are properties of how it is implemented, not of the identifier’s shape. An implementation that addresses entities correctly while abandoning the guarantees would satisfy the syntax and invert the purpose. The addressing, syntax, resolution, and comparison rules of §§4–8 may therefore be implemented freely, by anyone, for any purpose. The right to assert the scheme’s guarantees — to claim conformance, or to represent an implementation as providing verified personhood — is subject to conformance conditions, and to the evidence required to claim them, to be published in a subsequent revision of this specification. What is reserved is the representation, not the act: issuing identifiers is not gated, and an implementation may operate before those conditions are published, provided it claims nothing those conditions will govern. An unevidenced claim of conformance is non-conforming. Until that revision, the MUST-level requirements of this document, including §§9–10, bound what any implementation may claim.

(§3.4 is reserved for the evidence requirements accompanying those conditions. Section numbers in §3 are stable: the reserved section will be inserted at §3.4 without renumbering what follows.)

3.5 Embodied entities and humanoids

An unaccountable software agent can defraud; an unaccountable embodied machine can injure or kill. Embodiment therefore motivates this specification as strongly as anything on a screen — and the consequence is not a new structure, but the strictest application of the existing one.

3.5.1 A humanoid is a device

However human its form, a humanoid is a delegated entity: it MUST be identified under the scheme of its root entity (a personally owned humanoid under human://, a fleet humanoid under org://), it MUST carry an anchor chain per §3.2, verifiable from what it presents (§5.4), and it MUST NOT be an accountability terminus. There is no third scheme for machines, and there MUST NOT be one (§3.1): a scheme is an accountability declaration, and a machine that answered for itself is exactly the orphan machine that principle 3 (§1.2) exists to forbid. An embodied entity without a valid anchor chain is invalid — not degraded, not merely untrusted (§3.2) — and no conforming party interacts with it as an identified entity.

3.5.2 A humanoid cannot pass as a human

Entity type is part of the verification material and is proven, not asserted (§6.1). Two independent barriers keep the claim honest:

• A humanoid cannot hold a human identifier, because issuance requires a personhood proof (§3.2) that no machine can produce.
• A humanoid cannot borrow presence: a fresh authorization is a live act of the principal bound to a specific action, which the principal must actually perform. What makes an act live is method-dependent and this document does not fix it (§3.3, §6.4) — what it fixes is that the act cannot be delegated, recorded, or reproduced by the machine. Delegation is therefore always distinguishable from presence — a humanoid may provably act on behalf of its root, and can never truthfully present as the human being there.

3.5.3 Identification on demand

An embodied entity operating in space shared with humans MUST honor an in-person verification request from any physically present party, presenting proof that verifies per §7: its entity type, its category and tier where one is claimed (§4.4), and an anchor chain to a VALID accountable root, unrevoked at the time of presentation. It MUST NOT condition this on any prior relationship with the requester.

The duty takes the form the machine’s mode of operation permits:

• Hailable machines — those a person can practicably address in place (a humanoid, a ground robot, a stopped vehicle) — respond to the request on demand.
• Non-hailable machines — those that cannot practicably be addressed by the people they affect (an aircraft overhead, a vehicle in motion) — MUST broadcast the same proof periodically, at a cadence and range proportionate to their speed and reach, so that any affected party can verify without the machine’s cooperation.
• Occupant-carrying machines (a robotaxi, an autonomous shuttle) MUST present the proof before boarding — the moment of entrustment, while the passenger can still decline — and MUST continue to honor requests from occupants throughout carriage. For such machines the operating organization’s category will ordinarily be a Licensed one (§4.4), issued by the transport authority whose jurisdiction appears in its label (§4.5) — the digital form of the medallion.

What form the presentation takes — its encoding, channel, and range — is an open issue (§12). This section fixes the duty and the properties the proof must carry; it does not fix the wire form, and an implementation cannot be judged non-conforming for choosing one before that issue is settled.

Three properties the proof must carry, whatever form it takes.

• Freshness. The proof MUST be bound to the exchange in which it is presented, such that a recording of an earlier presentation does not verify. A machine’s identification is otherwise trivially portable, and an unaccountable vehicle replaying a licensed one’s broadcast would be indistinguishable from it.
• Anonymity of the verifier. A machine MUST NOT require a verifying party to identify itself, and MUST NOT condition the proof on anything that party discloses. A bystander who must announce themselves in order to check a machine has been charged for the right to verify, and most will decline to pay it.
• Currency of revocation. The proof MUST convey when the machine last confirmed its anchor chain unrevoked. A machine may be offline, and unrevoked at the time of presentation describes what the machine knows rather than what is true; a verifier who cannot tell how old that knowledge is cannot weigh it (§3.5.4).

Statutory remote-identification regimes for unmanned aircraft (FAA 14 CFR Part 89; EU Implementing Regulation 2019/947) already mandate broadcast identification, and a conforming broadcast is designed to be carried alongside or within them. It also repairs their principal privacy defect: a statutory broadcast reveals the operator’s presence and location to everyone while resolving accountability only through the regulator; a conforming broadcast proves accountability to everyone — a valid root answers for this machine, now — while revealing neither the operator’s identity nor the operator’s location to anyone absent lawful process.

The proof MUST NOT be required to reveal which human answers for a personally owned machine: accountability is provable in zero knowledge — a valid root exists, is unique, and is unrevoked — and full identity resolves only under lawful process. An organization-operated embodied entity discloses its operating organization, which is publicly verifiable (§10.2).

This inverts the privacy default deliberately, completing a pattern: a human is private by default (§10.1); an organization is public by default (§10.2); a machine acting among humans is identifiable by default. The default follows the accountability class, and the asymmetry is the point.

3.5.4 Revocation is a physical-safety parameter

For embodied entities, the revocation bound of §9.6 is a safety property, not an operational preference. Verifiers MUST validate an embodied entity’s anchor chain on every consequential physical action — from what the entity presents, never by querying a service (§5.4), which is why §3.5.3 requires the proof to convey how current the machine’s own revocation knowledge is. Implementations MUST document a revocation-to-rejection bound proportionate to the harm the entity can do. What a machine does when its chain dies — fail-safe behavior — is an open issue (§12); what this document fixes is that a machine whose chain is revoked has no valid identity to act under.

3.6 Software agents and digital twins

The embodied machine of §3.5 has a disembodied counterpart. Generative models make any face and any voice reproducible, which collapses the question every recipient once answered by inspection — is this really them? — into one that inspection can no longer answer at all. This specification replaces it with a question the identifier answers: does this carry their authority?

3.6.1 An agent is a delegated entity

A software agent — autonomous or interactive, including any agent presenting a human’s likeness — is a delegated entity under §3.2: typed as an agent in its verification material, anchored to exactly one root, and invalid without the chain. Everything in §3.1 applies unchanged; there is no agent scheme.

3.6.2 Representation is a scoped, revocable grant

A digital twin is a software agent whose delegation from its principal includes representation: authority to present the principal’s likeness, voice, or name in interaction. Representation is an authority like any other (§5.4) — scoped (which media, which contexts, which counterparties), time-bounded, attenuable, and revocable — and a twin acting outside its scope is unauthorized in exactly the way an absent chain is.

Representation discloses the principal, and it is no exception to §10.7 — it is disclosure by a different route. §10.7 forbids an identifier from encoding or yielding its root, and a representation credential does neither: the identifier remains opaque and unlinkable, and the principal is named by the grant, deliberately, because naming them is what the credential is for. A disclosure the entity authored is not a leak the identifier permitted.

3.6.3 Presence, representation, or nothing

A verifier evaluating an interaction that claims a person’s identity or likeness resolves it to exactly one of three states:

The third state is a deepfake, whatever its production quality. Clients MUST render the three states distinctly and MUST NOT render representation as presence — the analog of §4.4’s tier-rendering rule and §3.5.2’s rule for humanoids. An agent MUST disclose its agent status and its scope of representation on request to any counterparty in a session with it: identification-on-demand (§3.5.3), without the physics.

The shift in burden is the point. Today the recipient must detect fakery — an arms race the recipient is losing. Under this model the presenter must carry authority, and absence is dispositive. Authenticity stops being a forensic judgment and becomes a verification result.

4. Syntax

4.1 Grammar

The following uses the ABNF of RFC 5234; core rules (DIGIT) are as defined in its Appendix B. path-abempty, query, and fragment are as defined in RFC 3986. The grammar describes the normalized form of a reference: consumers fold to lowercase before applying it (§4.7), so a reference differing from this grammar only in case is well-formed and is normalized rather than rejected.

human-URI      = "human" "://" entity-ref path-abempty
                 [ "?" query ] [ "#" fragment ]

org-URI        = "org" "://" entity-ref path-abempty
                 [ "?" query ] [ "#" fragment ]

entity-ref     = encoded-id / label

; --- Encoded identifier: contains no "." ---
encoded-id     = "b" 52*127b32-char    ; multibase base32, lowercase, unpadded

; --- Label: always contains at least one "." ---
label          = name "." category
                 [ "." jurisdiction ]
                 [ "~" discriminator ]

name           = segment
category       = segment
jurisdiction   = country [ "." subdivision [ "." locality ] ]
country        = 2lcalpha             ; ISO 3166-1 alpha-2
subdivision    = 1*3( lcalpha / DIGIT )  ; ISO 3166-2 subdivision element
locality       = segment
discriminator  = "b" 52*127b32-char   ; a full-length key, encoded as §4.7

; A segment never begins or ends with "-" — see "Segment constraints" below.
segment        = alnum-char [ *253segment-char alnum-char ]   ; 255 max

alnum-char     = lcalpha / DIGIT
segment-char   = lcalpha / DIGIT / "-"
lcalpha        = %x61-7A                          ; "a".."z"
lchexdig       = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
b32-char       = lcalpha / %x32-37                ; "a".."z" / "2".."7" (RFC 4648 §6, lowercase)

Segment constraints. name, category, and locality share the segment production, which permits internal hyphens and forbids a leading or trailing one. Hyphens are permitted so that a multi-word term is expressible as a single label — computer-programming, real-estate — which the localized-term rule of §4.4 requires, since many category terms are multi-word in English and in most other languages. A leading or trailing hyphen is forbidden because it carries no meaning and creates pairs of references distinguishable only by a mark that is easily overlooked, in a namespace whose purpose includes resistance to impersonation.

The encoded identifier is at least 52 base32 characters because that is §3.2’s floor expressed in syntax: 52 characters carry 260 bits, and the 128 bits of collision resistance §3.2 requires cannot be had below 256. The bound is not a guess about future encodings — that is the upper bound’s job — and an implementation that shortens it violates §3.2 whatever its derivation.

A segment is at most 255 characters. The limit is not inherited from the domain name system, whose 63-octet label exists because a DNS label is length-prefixed by one octet with two bits reserved; these labels are never carried in that format and are under no such constraint. 255 is set to accommodate a legal name in full, since §6.3 requires a name to be the one the establishing document gives rather than a rendering chosen for brevity — and long names, whether from several surnames, a patronymic chain, or particles, are ordinary rather than exceptional.

Any label beginning xn-- is reserved and MUST NOT be assigned — the bare string xn-- being already excluded by the segment production, which forbids a trailing hyphen. This prefix signals a Punycode-encoded internationalized label in existing naming systems. The grammar of this version is ASCII-only and internationalized references are deferred (§12); reserving the prefix now means that if internationalized labels are later admitted under that convention, no previously assigned label is ambiguous between a literal ASCII string and an encoding.

4.2 Distinguishing a label from an identifier

A human or org URI carries either an identifier or a label. One containing no "." is an identifier. One containing at least one "." is a label. Because a category is REQUIRED in a label (§4.4), every label contains at least one ".", and the two are therefore unambiguously distinguishable without resolution. Implementations MUST use this test and MUST NOT rely on the multibase prefix to make the distinction.

4.3 Positional parsing of the label

• A separator is always a "." (dot).
• A label has between two and five dot-separated segments, optionally followed by "~" and a full-length discriminator (§4.6). An org label has at least three, because jurisdiction is required of it (§4.5).
• A label with more than five segments is invalid.

4.4 Categories

A label MUST include exactly one category. Requiring it means an unqualified label (human://arjun-singh) is not a valid identifier, which removes first-come bare labels — the most contested and most squatted resource in existing naming systems — from the namespace entirely.

A category has two independent properties: its vocabulary (where the token comes from) and its assurance (who attests the claim). They are orthogonal, and conflating them is a design error this section is written to prevent.

Vocabulary. Category tokens SHOULD be drawn from an existing international classification rather than defined ad hoc: ISIC (with published crosswalks to NACE and NAICS) for org activities; ISCO-08 for human occupations. The two do not substitute for each other — activity classifications describe organizations, occupation classifications describe persons.

An org category states an activity, and never a domain-name token. com, gov, edu and ngo classify nothing: they are allocation policy borrowed from another naming system, they are parochial — gov and edu denote United States institutions — and they duplicate, far less precisely, what the attestor already establishes. A companies register attesting a claim is the statement that the organization is a registered company; the token need not repeat it and MUST NOT substitute for it. What an organization is reaches a verifier through the tier and the attestor; what it does is the category. Borrowing a top-level domain also manufactures the resemblance §9.3 exists to warn against, in a namespace that is not the domain name system and carries none of its meanings. Where a taxonomy defines a numeric code, the code is canonical and any word form is a localized term for it: org://nvidia.2610.us.de and org://nvidia.semiconductors.us.de identify the same entity, and a resolver MUST treat them as equivalent (§8). Clients SHOULD display the term appropriate to the user’s language. A category appearing in a reference is a single token and expresses a multi-word term with hyphens (computer-programming); a category displayed to a user is unconstrained by this grammar and carries the spacing and diacritics of its language.

A displayed term MUST NOT be broader than the code. A client MUST display a term denoting the code exactly, or a concept narrower than it, and MUST NOT display one denoting a broader concept. ISCO-08 2652 is musicians, singers and composers: singer and composer are admissible because each lies within it; artist is not, because it names the minor group above, which also holds actors and dancers. Narrower is safe — a singer is genuinely within 2652 — while broader asserts a claim the holder never made, which is the overstatement this section exists to prevent. Where a vocabulary publishes its own hierarchy, that hierarchy settles the question; comparison and equivalence remain on the code and never on the displayed term (§8.2).

Where a language inflects the term, a client MUST NOT infer the inflection. Many languages render an occupation differently according to the holder — musicien and musicienne in French, and similarly across Spanish, German, Polish, Hebrew and others. A client MUST NOT derive that form from the holder’s name, likeness, or any other attribute. It uses the neutral or collective form the vocabulary provides, or the form the holder has supplied. Inferring it would make the rendering state something about the holder that the holder did not, and would reintroduce at the display layer exactly the inference the rest of this document refuses.

One token is reserved: person. A human label MAY use the category person, which claims an occupation of no kind and is held at the Asserted tier. It exists because this section requires exactly one category while ISCO-08 classifies occupations: without a reserved token, the readable layer of this namespace would be available only to those who have one, and a person with no occupation — or with one they decline to state — would have to assert something untrue or hold no label at all. Neither is acceptable in a namespace for people. There is no org equivalent and none is needed: an organization always has an activity, and ISIC covers it.

A person claim has no attestor, so it carries no jurisdiction — there is no issuing authority whose jurisdiction it could reflect (§4.5). Implementations MUST NOT condition its use on any credential, and MUST NOT treat it as a lesser or provisional form of label.

It claims nothing, and that is its value. What an undiscriminated label exposes is how few entities could be presenting it (§10.5). A common name held with person produces the largest entitled set the namespace can form, so it is the least correlatable label available — the holder with no credentials receives the strongest anonymity, rather than the weakest. The token is also not a statement about employment: it is the correct choice for anyone making no occupational claim, whatever their reason.

Assurance. A standard vocabulary standardizes the word, never the truth of the claim — classification is an interoperability property and carries no evidence. What a category claim proves is determined by who attests it. Every category claim carries exactly one assurance tier, which a resolver MUST report:

The tier attaches to the claim, not the token: the same token may be held at different tiers by different entities — musician is Asserted for the aspiring and Certified for the published — and a claim upgrades by acquiring a stronger attestor, without the reference changing.

An attestation is attributable or it is nothing. Where a claim is held above Asserted, resolution MUST return the org reference of each party whose attestation supports it. A tier that follows its attestor is worth only what the ability to identify that attestor is worth: a relying party who cannot tell who vouched cannot weigh the vouching, cannot check it against the attestor, and cannot discount an attestor later found unsound. This is §9.10’s rule for integrity attestations applied to category attestations. An Asserted claim has no attestor but its holder, and returns none.

An accountable point, not merely an accountable name. The org reference identifies who attested; it does not say where a consequence can be directed. An attestation MUST therefore designate an accountable point — a reference the attesting organization controls, resolvable and carrying a delivery endpoint (§6.1) — to which a party relying on the attestation can direct a question, a challenge, or a notice. A path selects it (§4.8); what lies behind it is the organization’s own affair, and this document requires that one exist and resolve, never what it contains. It MUST NOT resolve to a natural person’s identifier: the individual who signs an attestation is a human entity, private by default (§10.1), and a specification that exposed them by construction would make accountability a hazard to the accountable.

An attestation can be withdrawn, and a tier follows it down. A claim rises by acquiring a stronger attestor and falls the same way. Where an attestation supporting a claim is withdrawn, expires, or was made by a party that has since ceased to hold standing for it, the claim MUST fall to the tier it would hold without that attestation — to Asserted where nothing else supports it — and resolution MUST reflect the change within a stated bound, which implementations MUST document, which resolution MUST carry as a reliance bound (§6.1), and which MUST be proportionate to the consequence of relying on the withdrawn claim (§9.6). The reference does not change; only what resolution says about it does.

The reference itself deliberately encodes no assurance. Producers MUST NOT embed tier markers or assurance decorations of any kind in entity references — including the identity of any attestor, which reaches a verifier only through resolution (§6.1) — and clients MUST convey the tier through the interface itself, derived from resolution — never through characters composed into the displayed string. Naming an attestor in a reference fails for the same three reasons a tier marker does and one more of its own: it is writable by anyone, it says nothing until something signed confirms it, and it breaks the reference on every change of attestor. The additional reason is that attestors are plural — resolution returns each party whose attestation supports a claim, and one string cannot carry a set. What the reference does carry about an attestor is positional and no more: the jurisdiction of §4.5, which MUST agree with the attesting authority’s own. Two references identical in form may differ entirely in tier; this is intended. A tier signal carried in the string would be writable by anyone, anywhere the string appears without live verification — §9.2’s rule against authority in identifiers, applied to trust. It would also break references on every upgrade, since the claim strengthens while the reference stays constant. An org label’s required jurisdiction (§4.5) is no exception to this: it denotes legal personality, which does not move when an attestation is acquired or withdrawn.

An attestation counts toward a tier only if the attestor has standing for it: for Licensed, a statutory mandate whose digital issuance is verifiably bound to the authority; for Certified, recognized standing to attest that category. An attestation from an organization without that standing does not raise a claim above Asserted. Being a verified, accountable organization is not itself standing — an entity may be exactly what it says it is and still have no position from which to vouch for a claim of this kind, and a tier that did not say so would be worth only the diligence of whoever chose the attestor.

Clients MUST render the assurance tier of a category and MUST NOT present a claim at one tier in a manner visually indistinguishable from a claim at a higher tier. Failure to do so reintroduces exactly the impersonation weakness these schemes exist to remove.

4.5 Jurisdiction

Where present, jurisdiction is expressed outside-in — country, then subdivision, then locality — so that a prefix denotes a scope, references sort into geographic groupings, and the reading order runs from general to specific.

• The first jurisdiction segment MUST be an ISO 3166-1 alpha-2 country code.
• The second, if present, MUST be the subdivision element of an ISO 3166-2 code for that country (the portion following the hyphen: ca for US-CA).
• Jurisdiction MUST be fully qualified from the country downward and MUST NOT be truncated. human://arjun-singh.physician.us.ca is valid; a reference intending California but omitting the country is invalid, because human://arjun-singh.physician.ca denotes Canada.

This rule is normative because ISO 3166-1 country codes collide extensively with subdivision abbreviations in common use — ca (Canada / California), in (India / Indiana), de (Germany / Delaware), ga, md, la, mo, pa, id, and many others. ISO 3166-2 resolves this by namespacing subdivisions under their country; this specification preserves that discipline. In a namespace whose purpose includes resistance to impersonation, an identifier that different readers parse differently is a defect.

What the jurisdiction denotes, and whether it is required, differ by scheme.

For a human label, jurisdiction is OPTIONAL. Where present, its depth MUST reflect the actual jurisdiction of the authority that issued the category credential, not a preference of the holder. A state-issued license is …physician.us.ca; a city-issued license is …taxi.us.ny.nyc; a nationally licensed profession is …physician.in. It stays optional because a category and a jurisdiction are disclosures, and §10.8 requires that a credential be holdable without a label disclosing it.

For an org label, jurisdiction is REQUIRED, and it denotes something else: the jurisdiction of the register that establishes the organization’s legal personality (§3.2) — where it is incorporated, chartered, or otherwise constituted as a legal person. Not where it is licensed to operate, and not the jurisdiction of any party attesting its category.

The asymmetry is deliberate, and rests on three things:

• The privacy objection lapses. An org entity’s verification material and assurance metadata are publicly resolvable by design (§10.2), so a jurisdiction discloses nothing the scheme does not already publish. §10.8’s protection has nothing to protect here.
• It does the work §8.3 needs done. Two unrelated companies both trade as Merck, one German and one American; jurisdiction is what separates them, and a component present only sometimes separates them only sometimes.
• Accountability has to be locatable. A charter says where an organization may operate; incorporation says where it can be answered. An accountability claim nobody can locate is not one — which is §10.2’s argument carried one step further.

Incorporation rather than licence also keeps the reference stable. Licences are acquired, lapse, and move between jurisdictions; legal personality rarely moves at all. Because an org label’s jurisdiction does not follow its attestations, a claim still upgrades or falls without the reference changing (§4.4).

The string carries one fact; resolution carries the rest. An organization may be licensed in many jurisdictions by many authorities, and every one of those attestations reaches a verifier through resolution, which returns the org reference of each attestor supporting a claim (§4.4). The reference therefore carries the single stable fact that locates accountability, and never the plural volatile ones. A second jurisdiction component expressing both would place an unverifiable, incomplete, and frequently changing copy of resolvable data into a string — §4.4’s objection to assurance in a reference, in another form.

The jurisdiction is checkable against what resolution returns, and it MUST be checked. The comparator differs by scheme, and in both cases the two facts arrive in the same result and can be compared without consulting anything further:

• For a human label carrying a jurisdiction, resolution returns the org reference of each attestor supporting a claim held above Asserted (§4.4). The label’s jurisdiction and the attesting authority’s MUST agree. Where they do not, the attestation does not support the claim as written: the claim MUST fall to the tier it would hold without that attestation (§4.4), and a client MUST NOT render it at the attested tier.
• For an org label, resolution returns the register establishing the entity’s legal personality (§6.1). The label’s jurisdiction and that register’s MUST agree. Where they do not, §6.2’s requirement that the result carry evidence the identifier asserts the claimed label is not satisfied, and a client MUST NOT present the reference as verified.

A rule that binds the holder and is checked by no one is not a constraint on anything — and the jurisdiction is the one component of a label whose truth a relying party can verify from what resolution already returns.

An authority’s jurisdiction may have no ISO 3166 expression. Where it does not, the nearest enclosing level that does MUST be used, and the agreement required above is satisfied at that level. Some authorities operate over areas this vocabulary cannot name: a private regional accreditor, an interstate compact, a body whose remit spans several countries. A US regional accreditor is therefore written us, the nearest level ISO 3166 expresses, and a claim it attests is not made non-conforming by the absence of a finer one. The jurisdiction is a locator, never a measure of the attestor’s reach — what an attestation is worth is carried by the tier (§4.4), and its precise extent by the attestor itself, which §4.4 requires to be named, resolvable, and answerable.

Localities have no ISO standard. Implementations SHOULD use GeoNames identifiers as the canonical value with a localized place name as the display form, and MAY use UN/LOCODE where trade or transport usage makes it preferable.

4.6 Discriminators

A label is not unique. Two entities entitled to the same (name, category, jurisdiction) tuple both hold it, and the identifiers beneath are unrelated cryptographic values (§6.3, §8.3). Nothing is allocated: no claimant holds a tuple against another, and order of arrival confers nothing.

A discriminator is an optional suffix by which a holder makes itself addressable as exactly one entity among those entitled to a tuple, introduced by "~" so that it can never be confused with a jurisdiction segment. A holder MAY take one at any time. An implementation MUST NOT require one, MUST NOT assign one to settle a contest between entitled claimants, and MUST NOT treat its presence or absence as a mark of standing.

A discriminator MUST be a full-length cryptographic value, encoded as §4.7 encodes an identifier, and MUST NOT be a short or truncated one. The reason is that a short suffix buys nothing here. A coordinator able to check a candidate against those already held is a party able to enumerate the holders of a name, which §6.2 and §10.1 forbid — so a discriminator is self-assigned, without a check, and its uniqueness can come only from its length. At full length the probability that two entitled holders coincide is the collision probability of the underlying construction, which is the same assurance a key is trusted with everywhere else it is used. At four or eight characters it is not.

The discriminator is derived from the holder’s enrollment anchor, never from the identifier the label resolves to. The two are siblings beneath one root, not parent and child. This is required rather than merely convenient: §10.4 cycles the identifier a label denotes whenever the holder changes who may reach it, and a suffix computed from that identifier would change with it, renaming the holder for exercising a privacy control. The anchor does not move, so neither does the discriminator.

The readable form of a label is the undiscriminated one. A full-length suffix is not meant to be read, spoken, or typed; a reference bearing one is copied and pasted, as a wallet address is. What a person reads is arjun-singh.physician.us.ca — the name, the category, the jurisdiction, all of it meaningful — and what a machine resolves exactly is that label with the suffix appended. Implementations SHOULD display the readable form and carry the full form, and MUST NOT present a truncated discriminator as though it were the whole of one (§8.2).

Taking a discriminator does not oblige a holder to present it. Either form MAY be presented, in any context, at the holder’s choice. A holder obliged to present its discriminator once obtained would disclose, in every reference it made, that some other entity is entitled to the same tuple — turning its own label into a report about entities it has no standing to disclose (§8.3). What the two forms address differs, and no party may convert one into the other on a holder’s behalf (§8.2).

Discriminators MUST be unpredictable, and MUST NOT be assigned sequentially nor by any rule from which one holder’s discriminator can be derived from another’s. A full-length value from a cryptographic derivation satisfies this by construction; the requirement is stated because it constrains any other construction that might be offered.

What distinguishes holders of one tuple is verification material and attestation, never string form (§9.3). A widely known claimant and an unknown one, equally entitled to the name, hold the same label; resolution reports what each can prove, and that is the whole of the difference.

4.7 Normalization and case

The entity reference — both forms, in their entirety — is case-insensitive. The grammar in §4.1 defines it in lowercase; producers MUST emit lowercase, and consumers MUST fold the entity reference to lowercase before parsing, resolution, or comparison. Path, query, and fragment follow RFC 3986.

Case is the whole of it. Folding case, and mapping a category term to its canonical code (§4.4), are the only normalizations this document defines for a label. An implementation MUST NOT otherwise alter a label it was given — in particular it MUST NOT add or remove a discriminator, which changes what the label addresses rather than how it is written (§8.2).

An identifier is encoded in multibase base32: the prefix b, followed by the RFC 4648 §6 alphabet in lowercase, without padding. This encoding is chosen over shorter, case-sensitive alternatives such as base58btc (prefix z) because whatever sits after :// in a URI is routinely case-normalized by deployed tooling — proxies, loggers, and copy-paste paths — and an identifier that case-normalization silently corrupts is a defect in a URI scheme. An entity reference whose encoded identifier bears any other multibase prefix is invalid in URI form.

Other encodings of the same identifier’s bytes remain valid in non-URI contexts: DID methods retain their native encodings (base58btc is common), and equivalence across presentations is defined on the decoded bytes (§8.1), so the URI form and a DID form of the same entity compare equal after decoding. Within URI form, however, each identifier has exactly one canonical string — which forecloses the cache-splitting and visual-confusion defects that arise when one identifier admits several encodings.

4.8 Path, query, and fragment

The path selects an action or endpoint at the identified entity; its vocabulary is deliberately not enumerated here. Any path appearing in this document — /message, for instance — is illustrative only.

A URI MUST NOT carry credentials, capability tokens, secrets, or personal data in any component. Authority to act is conveyed in signed protocol messages, never in an identifier (§9.2).

4.9 Examples

Each example is annotated with the rule it exercises. For end-to-end scenarios showing these identifiers in use, see Appendix A (non-normative).

5. Semantics

5.1 What a URI identifies

A human or org URI identifies an entity. It does not identify a document, a host, a service instance, or a network location, and it makes no assertion about where that entity can be reached — that is the result of resolution (§6) and may change at any time without the identifier changing.

Two distinct identifiers may refer to the same entity without any party being able to establish that they do (§8.3): the same person holds distinct pairwise identifiers by design, unlinkable by every party but the entity itself (§10.3).

5.2 What dereferencing means

Dereferencing proceeds in two stages:

1. Resolution — the entity reference is resolved to verification material (keys, credentials, assurance metadata) and delivery endpoints; for a human entity, delivery endpoints are consent-gated material (§5.3).
2. Interaction — the client establishes a mutually authenticated, end-to-end encrypted session and exchanges signed messages, subject to §5.3.

5.3 Dereferencing is not delivery

Dereferencing a human URI MUST NOT, by itself, deliver content to the identified person, cause any state change at the target, or reveal to the requester whether that person exists.

A session with a human entity may be established only where the person has already consented to the relationship, or where the requester presents a first-contact request satisfying the conditions that person requires. Absent either, resolution of consent-gated material MUST fail without disclosing whether the entity exists, whether it declined, or whether the identifier was well-formed but unassigned. Implementations MUST NOT provide an oracle distinguishing these cases.

org entities are public by default (§10.2) and MAY expose published content and unsolicited-contact endpoints without prior consent.

5.4 Actions and authority

Where a path selects an action with consequences, the request MUST carry an authority chain terminating in an accountable root entity, and the verifier MUST reject a request whose chain is absent, expired, revoked, or insufficient in scope. Possession of a URI confers no authority whatsoever.

The unit is a session, not a token. A grant confers on one entity some part of what its granter holds, for a bounded period, over a stated class of actions. What authorizes a particular consequential action is a fresh signature made at the moment of acting and bound to that action. Both are required: a chain without a fresh signature is a bearer token, and a signature without a chain is an assertion with nothing behind it.

Scope narrows and never widens. No grant may confer more than its granter holds, and a verifier MUST take a chain’s effective scope to be the intersection of every grant in it. A grant purporting to widen scope does not partially succeed; the chain is invalid. Constraint therefore propagates without any party reaching past its own link — a root that narrows its grant to a delegate narrows, in that same act, everything the delegate has granted onward.

A verifier learns that authority exists, not whose. Verification MUST yield only that a valid, unique, unrevoked root authorized an action of this class within this scope — never which root, and never the identities of intermediate entities (§10.7). Where a counterparty needs to know whom it is dealing with, that disclosure is made within the session by the entity’s own act, on the same terms as any other disclosure (§8.3). Representation is not an exception to this: a digital twin’s grant discloses its principal because naming them is the credential’s purpose, and the disclosure is made by the grant rather than by an identifier or a chain (§3.6.2, §10.7).

Verification is local, and leaves no trace elsewhere. A verifier MUST be able to determine whether a chain holds from what it is presented, without querying any party about the chain, its grants, or the entities within it. No revocation list, status responder, or equivalent service may be required, and a verifier MUST NOT consult one: a verification that reaches outward tells whoever answers which authority was examined and when, which is precisely what the preceding requirement exists to prevent. A chain that is absent, expired, revoked, or out of scope MUST present identically to the verifier — as authority that does not hold — for the reason §6.5 gives.

An entity may revoke only what it granted. A granter MUST be able to revoke any grant it issued — an entity that can issue a grant it cannot revoke has issued something it does not control — and MUST NOT be able to revoke a grant issued by another, at any depth. A root that wants a sub-delegate stopped asks the delegate; a delegate that will not control its own delegates may itself be revoked, collapsing every grant beneath it.

That limit is deliberate, and it constrains power rather than the mechanism. The delegate holds a relationship the root does not, and requiring the root to act through it makes the exercise visible to the party best placed to object, contestable by that party, and costly to the root, which must forfeit an entire branch to insist. A root able to reach past its delegate could punish quietly and selectively, for a reason it never had to state, and the record would show nothing. Over-revocation is the safe failure: collapsing a branch is recoverable in a way that an unaccountable machine still acting is not (§3.5.4). This is the rule §10.11 states for disclosure and §4.4 for attestation, in a third place — no party may act alone against someone with whom it has no relationship.

6. Resolution

6.1 Requirements on a resolver

A resolver maps an entity reference to:

• the entity’s current verification material;
• its assurance metadata, including the category tier (§4.4), the org identifier of each entity whose attestation supports that tier, and the anchor chain for a delegated entity;
• an identifier of the method under which its verification material was issued;
• its delivery endpoints (consent-gated for human entities: §5.3);
• for a label, the identifier it denotes;
• for an org entity, the register establishing its legal personality (§3.2) — the authority and its jurisdiction, so that §4.5’s required jurisdiction can be checked rather than trusted;
• a reliance bound — the time after which the result MUST NOT be relied on without resolving again.

The bound travels with the result, and documenting it is not sufficient. §4.4 and §9.6 each require a change — a withdrawn attestation, a revoked chain — to take effect within a bound the implementation documents. That answer is coherent for a client dealing with one implementation and incoherent for the client this specification requires: §6.4 obliges a resolver to handle more than one method, so a conforming client holds material issued under several methods by several implementations at once, and cannot know which party’s documented bound governs which item it is holding. The bound therefore MUST be carried in the result. §9.4’s duty to retain previously observed verification material is a duty to detect substitution, and is not a licence to rely on what was retained for as long as it happens to be held.

A bound is a property of a method, never of an entity. It MUST NOT vary in any way that distinguishes one entity from another within a method. A reliance period peculiar to one entity is a correlator, and would defeat §10.3 by the same route §6.1 already closes when it forbids exposing method identity at a granularity finer than the method itself.

A resolver MUST NOT hold personal data, and MUST NOT be required to hold personal data in order to perform resolution. Resolution operates on verification material and assurance metadata alone.

A resolver never receives a label. Resolution operates on the underlying cryptographic values, and a label is not among them. A resolver MUST NOT receive a label, nor any value from which a label can be determined — at any instant, however confined — and MUST NOT be able to acquire one from what it does receive. The test is determinacy, not derivation: what is forbidden is a value that identifies the label, not every value computed from one. A digest of a label is determinative, and forbidden for the reason §6.3 gives. Stated as a prohibition on derivation rather than on determinacy, this requirement would forbid every construction capable of satisfying it — and how an implementation does satisfy it is not specified here. No step of resolution requires a label to reach infrastructure, and an implementation that sends one has created a place where labels exist: a place where they can be logged, leaked, or compelled. §10.11 holds only for as long as infrastructure has nothing to yield.

Method identity is assurance metadata: like the assurance tier (§4.4), it MUST NOT be encoded in the entity reference, and reaches a verifier only through resolution. Implementations MUST NOT expose method identity at a granularity finer than the method itself — an identifier disclosing which deployment, instance, or enrollment cohort issued it narrows the population within which its holder is anonymous, and a sufficiently narrow population is an identification. A verifier may decline a method; it may not be handed the means to single out a person within one.

A resolver MUST be operated by an entity identified by an org URI, and every resolution response MUST carry that reference. Resolution is infrastructure on which other entities depend: where it fails, misreports, or is compromised (§9.4), an accountable party must be reachable in fact and not merely provable in the abstract. A natural person is never required to place their own identifier in that position — an individual operating a resolver does so through an organization, whose disclosure costs nothing that §10.2 does not already make public. The same requirement governs issuance of identifiers to parties other than the operator.

This requirement governs the operation of a role others depend upon. It does not restrict who may write, publish, or distribute implementing software — that is unrestricted (§14.2) — and it does not reach an instance serving only its own operator.

6.2 A label resolves through the identifiers it denotes

A label is resolved by first resolving it to the identifier or identifiers it denotes, then resolving each. A label is not unique (§4.6): where more than one entity is entitled to the same label, resolution returns each of them whose consent reaches the querier (§6.5) — never the set of holders, which no operation discloses (§10.1).

For each identifier returned, the result MUST carry evidence, verifiable by the querier, that the identifier asserts the claimed label — so that a label cannot be pointed at an entity that has not claimed it. The querier holds the label and can check this; the resolver does not hold it and cannot (§6.1).

The result MUST carry the assurance metadata of §6.1 for each, tier and attestors above all: where a label denotes more than one entity, that metadata is the only thing that distinguishes them (§4.4, §4.6). A resolver MUST NOT order, rank, or otherwise privilege one over another — ranking is a judgement about standing, and §4.6 leaves none to make.

6.3 Claiming a label requires proving the name

An implementation MUST NOT assign a label unless the claimant demonstrates entitlement to both components:

• the name — by a verified legal name, or a verified registered pseudonym evidenced by a trademark, rights-organization, or ISNI registration;
• the category — by the credential appropriate to its tier (§4.4).

The name is the one the document gives. A label’s name segment is the verified name as the establishing document renders it — where that document carries a machine-readable Latin rendering, that rendering — reduced to the grammar of §4.1 by case folding, removal of diacritics, and replacement of each space by a hyphen, and by nothing else. A claimant MUST NOT choose among renderings, abbreviate, reorder, or omit any part, and an implementation MUST NOT assign a name that the document does not yield. Whatever the naming system — two surnames, a patronymic with no family name, a single legal name — the label follows the document rather than a rule imposed on it, which is why no rule is imposed. Where a document yields nothing admissible under §4.1, no label is assigned under it, and the entity is addressed by its identifier, which needs none (§12).

The reserved category requires no further evidence. Entitlement to person (§4.4) is established by the personhood proof against which every human identifier is issued (§3.2). It is the one category whose evidence already exists at the moment a label could be claimed, and an implementation MUST NOT demand any further credential for it. A requirement to prove one is a person, imposed on a party already proven to be one, is a gate with nothing behind it.

Two questions of composition follow from that rule, and are answered here rather than left to be inferred.

An acronym is a name or it is nothing. One is admissible as a name only where the acronym is itself the verified name — registered as a trademark or trade name held by the same legal person, and evidenced on the second path above. It is never admissible as a shortening of a longer verified name, which the preceding paragraph already forbids. An initialism a claimant coins for its own convenience is not a name, however widely it is spoken.

Legal-form suffixes are not part of the name. Inc., Corporation, N.A., GmbH, Ltd. and their equivalents are omitted, and this is not the omission forbidden above: they denote the form of the legal person, not its name. A register applying a distinguishability test will not admit a name distinguished from an existing one only by its designator, so within a jurisdiction the suffix separates nothing the register has not already separated; where a register is more permissive, two entities simply hold the same label, which §4.6 contemplates and a discriminator answers. The jurisdiction component states precisely what a designator states approximately (§4.5). And a statutory conversion — a limited liability company becoming a corporation — changes the designator while the register treats the entity as continuous, so a suffix-bearing label would break a reference where no change of legal person occurred (§4.4).

Two entities entitled to the same name may both hold it: the reference distinguishes them by discriminator (§4.6), and the identifiers beneath are unrelated cryptographic values. Sameness of label is never sameness of entity (§8.3).

Entitlement is proved to an implementation, never disclosed to it. The evidence establishing entitlement — an identity document, a credential, a registration record — MUST be evaluated where it already resides, under the claimant’s control, and the implementation MUST receive only a proof that the required predicate holds. It MUST NOT receive the evidence, an image or transcription of it, or any attribute it carries — and this includes the name and the category themselves.

Nor may it receive them in hashed or otherwise derived form. Labels are drawn from a small and guessable space: a party holding a list of candidate labels can derive the list and match it against whatever it has stored, so a digest of a label protects nothing the label itself would not. Data-protection regulators have reached the same conclusion about hashed national identifiers, after leaked registries made cohort-wide reversal a matter of routine computation. A requirement satisfied by storing a digest is a requirement not satisfied at all.

What an implementation receives is a proof that this claimant is entitled to the label and category being claimed. What it does not receive is which label, which category, any value from which either can be recovered, or anything else the evidence carries: date and place of birth, document number, nationality, address, likeness. A document proving one attribute discloses a dozen, and an implementation that accepts it in order to read one has taken custody of all of them.

Retention is therefore not the operative limit. Possession is. An implementation that never receives the evidence has nothing to retain, nothing to lose in a breach, and nothing to produce under compulsion (§10.11) — and it cannot build the correlation §10.6 forbids, because it was never handed the material to build it from.

What distinguishes this namespace from first-come naming systems is not the label but what lies beneath it. In DNS the name is the identity, so whoever registers first holds it against everyone else, including anyone with a better claim. Here a label identifies no one by itself: it is bound to a unique cryptographic identifier, and two entities equally entitled to a label both hold it (§4.6, §8.3). Entitlement — the name and the category, proven together — governs who may be assigned a label; the identifier beneath governs who they are.

6.4 Method plurality is required

Resolvers MUST be capable of resolving entities described under more than one DID method, and an implementation that can resolve only a single method does not conform. This requirement exists to prevent capture of the schemes by any single registry operator, and is normative for that reason rather than merely aspirational.

6.5 Failure

Resolution failures MUST be reported in a manner that does not distinguish among not assigned, assigned but not consented, and no longer resolving — the last covering every reason an identifier that once resolved has ceased to, including a cycle under §10.4. This is required by §5.3 and §10.4, and is why the failure mode is specified rather than left to implementations.

7. Operations on identifiers

An implementation need not offer every operation: a client that only checks presented material is not required to resolve. But any operation it does offer MUST behave as defined here.

Presented material arrives from the party being checked, never from a resolver. A counterparty supplies it in establishing a session (§5.2); an embodied machine supplies it on demand, in a form that must verify without network access (§3.5.3); the party acting supplies an authority chain, and §5.4 forbids a verifier consulting anyone about it. The two operations run in opposite directions — resolve reaches an entity whose reference you already hold, while verify examines what is in front of you — so a client that only verifies is not a partial implementation. For those flows it is the whole of what is required, and reaching outward would be a defect rather than a convenience.

• resolve — as in §6.
• verify — check that presented material satisfies a stated requirement (unique human; category at a stated tier; anchor chain to a stated root). A verifier MUST NOT learn, from a verification, anything beyond whether the stated requirement is satisfied — not which entity presented the material, and not any identifier that entity holds in any context. Where a requirement cannot be checked without disclosing more than it asks, the excess is not incidental: it is a defect in the verification, and the implementation MUST NOT perform it.
• act — submit a signed action with an authority chain (§5.4).

There is deliberately no operation that enumerates entities, lists the holders of a category or jurisdiction, or lets a party learn of a reference it was not given. Resolution answers about a reference the querier already holds; it is not a search. Implementations MUST NOT provide such an operation, and MUST NOT provide by aggregation, bulk interface, or unmetered access what the absence of one withholds.

8. Comparison

8.1 Identifiers

Two identifiers are equivalent if and only if they are identical after case-folding to lowercase (§4.7) and decoding the multibase value. Comparison is on the decoded bytes, not the encoded string. The same rule defines equivalence across presentations: an encoded identifier in URI form and the same identifier expressed under a DID method are equivalent when their decoded bytes are equal.

8.2 Label form

Two labels are equivalent if and only if they agree in every component — name, category, jurisdiction, and discriminator — after case-folding to lowercase and after mapping any category term to its canonical code (§4.4). org://nvidia.semiconductors.us.de and org://nvidia.2610.us.de are therefore equivalent; human://arjun-singh.physician.us.ca and human://arjun-singh.physician.us.ca~b4kq7mzr2xp5hv8n3cf6jw9tsd2gy7ba5ekn8rqu4mvx6zpc3hjf9 are not.

Equivalence of labels establishes nothing about entities, in either direction. Two equivalent labels may denote different entities, because a label is not unique and every entity entitled to one holds it (§4.6). Two labels that are not equivalent may denote the same entity, because an entity may hold several — and because a discriminated label denotes one of the entities its undecorated form denotes, not a different one. Only identifiers settle identity (§8.1, §8.3).

A discriminator MUST NOT be added or removed in the course of comparison. Of any two labels, this pair is the one whose forms are related by construction — one is the other with a suffix — and the relation invites a substitution that both forms forbid. Dropping a discriminator widens the reference from one entity to every entity entitled to the tuple, among which §6.2 leaves nothing by which to choose. Supplying one narrows a reference the presenter left wide, which §4.6 leaves to the presenter alone. An implementation MUST compare, store, and forward a label in the form it was presented, and MUST NOT derive either form from the other.

8.3 What comparison does not establish

A single entity may hold multiple identifiers that are cryptographically unlinkable by design. Implementations MUST NOT infer from two identifiers being different that they denote different entities, nor attempt to correlate them.

The converse holds equally. Two entities may bear the same name: there is more than one Taylor Swift, and two unrelated companies both trade as Merck — one German and one American. Jurisdiction (§4.5) separates them where they sit in different ones, and a discriminator (§4.6) does where one has been taken. For the two Mercks, jurisdiction always separates: an org label carries one by requirement (§4.5). For two humans of the same name, neither component is required, and where neither applies the two hold the identical label. What a client displays may still be identical for both. Only the identifier beneath determines who is denoted; the label is never the identifier (§6.3).

An entity may demonstrate to a counterparty of its choosing that two of its identifiers are both its own, by proving control of each; no party may assert such an association on any other basis. The demonstration binds only the parties present for it, and an implementation MUST NOT produce from one any artifact by which a recipient could prove the association to a third party.

Nor can one entity disclose another. The identifier one entity holds for another is specific to that pair (§10.3): passed to a third party, it resolves to nothing for them. Reachability cannot be conveyed by a party that merely holds it — an entity becomes reachable to a new counterparty only by its own act.

9. Security considerations

This section is titled per convention (RFC 3552); its contents are requirements, not advice. Every MUST in this document is a conformance condition, and this section’s heading does not weaken the ones it contains: an implementation that violates one is non-conforming (§3.3) and may not represent itself as implementing these schemes for as long as the violation persists — non-conformance attaches to the state, not the history, and is cured by correction. Requirements enforceable by construction are enforced by peers: an invalid chain, an unauthenticated session, or an enumeration oracle fails at the protocol, not at a policy. The remainder of the enforcement architecture accompanies the conformance conditions (§3.3) in a subsequent revision.

9.1 Identifiers are not secrets and confer nothing. A URI contains no key material and no credential. A label does state a name, a category, and often a location — disclosures its holder chose to make (§10.8) — but possession grants no access: interaction requires mutual authentication, and action requires an authority chain (§5.4).

9.2 Never place authority in an identifier. Implementations MUST NOT define query parameters or path conventions carrying capability tokens, bearer credentials, or personal data. Identifiers are logged, shared, cached, and pasted; authority carried in them becomes authority leaked by them. This constraint is deliberate: the practice of embedding action and authority in dereferenceable strings is the origin of a large fraction of the phishing and injection exposure of the existing web.

9.3 Impersonation. Verification is end-to-end against the entity’s own material; visual similarity of identifiers confers nothing. Clients MUST present verification status and assurance tier rather than raw identifiers alone, and MUST honor §4.4’s rendering requirement. Where a client displays a label, it MUST apply confusable-character detection (Unicode TR39). The grammar restricts references to ASCII, but what a client displays is not always the reference: a category is commonly rendered as its localized term, in whatever script that language uses (§4.4). The attack lives in the rendering, not in the reference.

A label can still be mistaken for a domain name, though less easily than it once could: §4.4 excludes top-level-domain tokens from the category vocabulary and §4.5 requires a jurisdiction, so org://nvidia.2610.us.de looks little like nvidia.com. What remains is the name segment, which is frequently the very string a reader associates with an organization’s domain, and a truncated or carelessly rendered reference recovers the resemblance immediately. Clients MUST NOT render a reference in a manner that invites it to be read as a domain, and MUST convey the resolved category and tier alongside it. A reference is not a domain and carries none of a domain’s meanings; a reader who mistakes one for the other has been misled by the interface rather than by the string.

9.4 Resolver compromise. A compromised resolver can deny service and can attempt substitution. Verification material MUST therefore be verifiable independently of the resolver that supplied it — through the entity’s signature chain — so that a resolver cannot forge a binding undetected. Clients MUST retain previously observed verification material and MUST treat a change unaccompanied by a valid entry in the entity’s own rotation record (§2) as a verification failure, not a curiosity. An entry is valid for this purpose only if it is signed under material the client has already accepted for that entity, so that a resolver substituting material cannot also mint the record that would excuse the substitution. This section governs a relationship that continues; it does not reach an identifier cycled under §10.4, and MUST NOT be read to require a record linking a severed identifier to any successor.

9.5 Enumeration and existence disclosure. §6.5 and §7 exist to prevent an adversary from using resolution as an oracle over the population. Implementations that leak existence through timing, error codes, rate-limit behavior, or any other observable difference do not conform.

9.6 Anchor-chain validation. A delegated entity’s chain MUST be validated to a root on every consequential use. Revocation of a chain MUST take effect within a stated bound, which implementations MUST document, which resolution MUST carry as a reliance bound (§6.1), and which MUST be proportionate to the consequence of acting on a revoked chain.

9.7 Downgrade. Where these schemes are bridged into https for legacy access, the bridge is outside the guarantees of this document, and clients MUST NOT represent material obtained through such a bridge as carrying the same assurance.

9.8 Relayed presence. An embodied machine that relays a remotely produced human authorization as though the human were physically present is the physical analog of a replay attack. Freshness proofs are bound to the action and epoch; implementations MUST NOT represent a remotely produced authorization as physical presence, and the binding of presence claims to local physical circumstances is an open issue (§12).

9.9 Synthetic media. A recipient MUST NOT treat content analysis — any technique that infers, from received image, audio, or video, whether that content was synthetically generated — as establishing who is party to an interaction. Such inference is probabilistic, degrades as generative models improve, and cannot in principle separate an authorized synthetic likeness (§3.6.2) from an unauthorized one, because both are synthetic. What establishes the parties to an interaction is the classification of §3.6.3, and nothing else.

This prohibition concerns substitution at the point of receipt. It does not reach analysis of a biometric sample at the point of capture: establishing that a live subject is present at a sensor — in real time, with that subject physically present at the sensor, as a precondition to producing a proof — answers a different question from inference about received content, and is a component of producing a presence assertion rather than a substitute for verifying one. Nothing in this section restricts it, and the presence limb of §3.6.3 presupposes it. The integrity of the capturing device is a separate question, addressed in §9.10.

Content-provenance systems (e.g., C2PA) are complementary rather than equivalent: they bind media to a capture or production source, while these schemes bind an interaction to an accountable authority. Neither substitutes for the other.

9.10 Capture-device integrity. A presence assertion is produced by software running on a device, and a verifier who was not there must decide whether to believe that software. The attacker’s cheapest move is not to defeat the capture but to skip it — to emit a well-formed assertion having captured nothing — so an assertion is worth no more than the evidence that it came from the pipeline that was supposed to produce it.

Two distinct properties bear on that, and neither substitutes for the other. The capturing device carries an anchor chain (§3.2), establishing that an accountable party answers for it. And it attests its own integrity, establishing that it is in a sound state: the genuine build, an unmodified platform, key material held where it cannot be extracted. A device anchored to an impeccably accountable party can still be running modified software.

The capturing device need not belong to the subject: a person may authenticate at a device they do not own and have never used, and what distinguishes capture from receipt (§9.9) is the subject’s live presence at the sensor, not the ownership of the hardware. Ownership creates no exception in the other direction either. A device its subject owns is no less capable of being compromised than one they borrow, and it is the device they use constantly and trust implicitly; a rule that waived attestation for the familiar device would waive it exactly where an attacker prefers to be. An attestation establishes that a device is sound, never whose it is (§10.7).

An attestation must terminate in an accountable entity. An attestation identifying the software that produced an assertion is worth exactly what the identified publisher is worth, and “the genuine build of an unaccountable party” establishes almost nothing — the party who would write software to fabricate assertions is the same party who signs it. The publisher identified by an attestation MUST therefore resolve to an entity under these schemes, and where the software is made available to parties other than that publisher, the entity MUST be identified by an org URI. This is §6.1’s rule, for §6.1’s reason: producing assertions that strangers rely upon is a role others depend upon, and a sanction that cannot be served on anyone is not a sanction. Nothing here restricts who may write or distribute implementing software (§14.2), and software a person writes and runs only for themselves is unaffected; what is restricted is presenting assertions to third parties from behind a publisher no one can reach.

Attestation is graduated, and is not a precondition of participation. Its absence weakens an assertion; it does not void one. Capture itself requires only a sensor and is independent of platform, vendor, and operating system, whereas attestation is available only where hardware and firmware provide it — so a specification that made attestation a condition of producing a valid assertion would confine the protocol to recent commercial devices and exclude exactly the populations a claim about all humans most needs to reach. Implementations MUST NOT condition participation on a capturing device’s ability to attest. A verifier MAY require attestation for a given purpose, and MUST be able to determine whether an assertion carries one; what suffices is the verifier’s judgment and depends on what is at stake. Where no attestation accompanies an assertion, no publisher is identified either, and the verifier weighs an assertion whose producing software is unknown — which is the weakest case this section contemplates, and a further reason the determination belongs to the verifier rather than to this document. What an attestation must establish, how it is bound to the assertion it accompanies, and what follows from its absence are open issues (§12).

10. Privacy considerations

The preamble of §9 applies here in full.

10.1 human is private by default. Assignment of a human identifier MUST NOT cause the entity to become discoverable. The default state of a conforming implementation is that an entity cannot be found, enumerated, or confirmed to exist.

Visibility is per context and never global. An entity sets, within each context in which it participates, whether it is visible there and who may reach it (§5.3); that setting governs that context alone. An implementation MUST NOT apply a visibility setting made in one context to any other, MUST NOT expose one context’s setting to another, and MUST NOT provide any means by which visibility in one context may be inferred from visibility, or its absence, in another. An entity MUST be able to see what it has granted. An implementation MUST be able to present to an entity, on request, the current state of what that entity has granted within each context in which it participates — who may reach it, and what is visible there — and MUST make that available to that entity alone. A right to withdraw (§10.4) exercised over a set the holder cannot enumerate reaches only what the holder happens to remember, which is the defect §10.4 identifies one layer down: a control that changes only what an interface displays is not a control. This creates no operation of §7 and no exception to it. An entity’s pairwise identifiers are derivable by that entity and by no one else (§10.3), so what is required here is that an implementation show an entity its own state — never that any party become able to ask about another’s.

There is no act by which an entity becomes globally visible, and none by which it could be made so. Holding a label (§4) is not that act either: it makes one label recognizable wherever that label is used (§10.5), and makes the entity visible nowhere else.

10.2 org is public by default. Organizational transparency is the purpose of the org scheme. An org entity’s verification material and assurance metadata MUST be publicly resolvable: an accountability claim that cannot be checked is not one. No organization is obliged to obtain an org identifier — but obtaining one is the affirmative act by which an organization declares itself accountable, and that declaration must be verifiable by anyone. What is publicly checkable is the label. A party holding one resolves it, and the result carries evidence — verifiable by that party, because it holds the label — that the identifier denoted asserts that label (§6.2). That check is available to anyone who has been given the label, and it is the whole of the accountability guarantee. It is not available from a bare identifier: a resolver never receives a label (§6.1), so resolution discloses verification material, assurance metadata, and attestors, and never the name of the entity resolved. An organization’s identifiers are accordingly no more linkable to one another than any other entity’s. What an organization publishes beyond that, and whether it accepts unsolicited contact, remain its own choice (§5.3). This asymmetry with §10.1 is intentional (principle 7, §1.2) and is the principal reason two schemes exist rather than one.

An implementation MUST NOT provide any means to enumerate an organization’s identifiers, to discover its counterparties, or to enumerate the contexts (§2) in which it holds identifiers. Accountability requires that a party be identifiable in each of its dealings; it does not require that its dealings be visible to anyone outside them. An organization’s counterparties, contracts, suppliers, and negotiations are as confidential under this specification as those of any other party.

10.3 Unlinkability. An entity’s identifiers MUST be distinct for each counterparty. An implementation MUST derive a distinct identifier for each counterparty an entity deals with, in each context in which it participates; MUST NOT provide any means by which an identifier held by one counterparty is presented to another; and MUST NOT condition participation on an entity maintaining a persistent identifier.

Distinctness per context is the coarser grouping, and on its own it is not enough. A context may hold many counterparties (§2), so an identifier distinct per context but common to every counterparty within one leaves each of them able to correlate its dealings with every other’s — the correlation this section exists to prevent, performed by the parties best placed to perform it and requiring nothing of the infrastructure. Context governs the reach of a setting (§10.4); the counterparty governs the reach of an identifier (§8.3).

One exception, and it is the readable layer. The identifier a label denotes is scoped to the context, not to a counterparty. Two reasons, and the first is decisive on its own. A pairwise identifier presupposes a pair, and a label does not — a label is given out, and is resolved by parties the entity has no prior relationship with; an org label is resolvable by anyone at all (§10.2), where no pair exists to derive an identifier from. And §10.6 confines the readable layer’s exposure to exactly one identifier per label: were a label to denote a different identifier for each party holding it, that exception would widen with every counterparty instead of staying where §10.6 puts it. What a label discloses is bounded because it denotes one thing.

This is not a weakening. Parties holding the same label can already correlate their dealings with its holder, and §10.5 says so plainly rather than pretending otherwise — the string is the same string, presentation is never compelled, and the holder is told before the first label is assigned. What §10.6 protects is every other identifier the entity holds, and that protection is untouched.

Distinctness alone is insufficient. Correlation MUST NOT be possible from the identifiers themselves, and an implementation MUST NOT retain, derive, or otherwise be able to obtain any mapping among an entity’s identifiers. An implementation that issues distinct identifiers while holding the correspondence between them has satisfied the form of this requirement and defeated its purpose; what is required is that an entity’s pairwise identifiers be derivable by the entity and unlinkable by everyone else, the implementation included.

Recognition remains fully available, and is an affirmative act performed upon distinct identifiers rather than a reason to share one. An entity that wishes to be discoverable in a context makes itself visible there (§10.1); an entity that wishes a label others can recognize holds a label (§4), itself backed by its own label identifier; an entity that wishes two of its identifiers associated proves control of both to whoever should hold that association (§8.3). None of these requires, and none produces, a single identifier used in more than one context — and discovery mechanisms that operate by mutual proof between two parties require no persistent identifier at all.

10.4 A change of visibility or reachability MUST cycle the identifiers it governs. When an entity changes, within a context, whether it is visible there or who may reach it, the implementation MUST cycle every identifier that setting governs — one identifier where the change concerns a single counterparty, every identifier in a context where the change concerns that context. A setting that leaves the identifier standing changes only what an interface displays: every party that resolved the entity under the previous setting still holds a working identifier, and the entity has withdrawn nothing. This is the rule of §10.11 applied to the entity’s own side — what protects an entity is what its counterparties are unable to do, never what they have been asked not to do.

A cycle under this section is not the rotation of §9.4, and the two MUST NOT be conflated. §9.4 governs continuity of verification material within a relationship that continues, and requires a rotation record so that a retained counterparty can follow the transition and a substitution cannot pass for one. A cycle under this section severs a relationship the entity is leaving: a counterparty withdrawn from MUST observe only that the identifier no longer resolves, and MUST NOT be given a successor, a rotation record, or any means to determine whether one exists.

A label survives a cycle; the identifier beneath it does not. Where the identifier a label denotes is cycled under this section, the label is unchanged: its binding is re-asserted to the successor, parties that may still resolve obtain the successor, and parties withdrawn from observe only that resolution fails (§6.5). It follows that no component of a label may be computed from the identifier it denotes. A discriminator derived from that identifier, for instance, would change whenever the identifier did — so every change of a privacy setting would rename the entity, and an entity would be punished for exercising the control this section exists to give it. A label is durable; the identifier beneath it is not, and is meant not to be. The readable layer has to be stable while the layer beneath it changes.

This does not qualify §10.6’s exception, which permits a party holding a label to confirm the identifier it denotes. What is forbidden here is the reverse direction — the label being computed from that identifier — which is a durability requirement rather than a privacy one, and the two are independent.

A single change may do both at once. Where a context-wide change removes access from some counterparties and preserves it for others, both sections apply and neither is optional: the identifiers of the parties withdrawn from are cycled under this section and given no successor, and the parties retained are carried across under §9.4 by a rotation record issued to each of them alone. An implementation MUST NOT treat a change of setting as license to sever a relationship the entity has not ended — what this section requires is that a withdrawal be effective, not that a setting be destructive. Two requirements follow, and they are separate.

Each rotation record reaches one counterparty and no one else. An entity holds a different identifier for every counterparty (§10.3), so each record concerns exactly one of them. A record MUST reach that counterparty alone.

No one may work out who was kept and who was dropped. No party — the infrastructure included — may be able to determine which counterparties were retained and which were withdrawn from. This binds every consequence of the change, not only its contents: how many records are sent, when they are sent, where they go, and anything else an observer could count or time. How that is achieved is not specified here; that it is achieved is a conformance condition. Where a reference resolves for anyone (§10.2), its continuity is public along with it.

10.5 Only the label can be correlated. The identifiers beneath a reference are cryptographically separate (§10.6) and the label is not, so the label is the only thing about an entity that two of its counterparties could hold in common. Nothing is published to make it so: a label is revealed by the entity to a counterparty, within a context, and reaches no one else (§7).

A discriminated label identifies exactly one entity, by construction. Where a holder presents the full form, the question below does not arise: the suffix is full-length, so the label denotes one entity and correlates as precisely as an identifier would. Everything that follows concerns the undiscriminated form, which is the readable one and the one a person ordinarily sees.

What an undiscriminated label exposes is how few entities could be presenting it. A label denotes a set, not an entity (§4.6, §6.2), so two counterparties comparing notes learn that each dealt with someone entitled to the same tuple — never that they dealt with the same one. What that is worth to them depends entirely on how large the entitled set is, and no operation discloses its size (§6.2). A common name in a broad category correlates weakly; a rare name correlates exactly. The holder is better placed than any implementation to know which case it is in, and this document does not pretend otherwise.

The intuition to correct is that a pseudonym is the safer choice. A registered pseudonym is unique by construction — a trademark, rights-organization, or ISNI registration is granted against the field, which is exactly what makes it admissible as entitlement (§6.3) — so it is the strongest correlator a label can carry, and its second use establishes what neither counterparty could otherwise know. A discriminator does the same thing deliberately: collapsing the entitled set to one is its purpose (§4.6). Nothing is resolved in any of this, and no operation this specification defines is involved: a human-readable string is readable by humans.

Implementations MUST make this plain when a label is first assigned, and MUST NOT require a single label to be used everywhere. Where a label states an attested claim (§4.4), the string is fixed by what was attested and by the entitlement proved for it (§6.3), and an implementation MUST NOT require a variation that would be false.

A minimal-disclosure label is always available. Where an entity would rather hold a label than an identifier but not state an occupation, the reserved category person (§4.4) is entitled by the personhood proof it already holds (§6.3) and discloses nothing beyond the name. It is the floor of this section’s trade: a readable, reachable face that narrows the entitled set by nothing at all.

A human entity MUST NOT be required to present a label at all. An implementation MUST NOT condition participation in a context, visibility within it, reachability, or any operation of §7 on an entity holding or presenting one; an encoded identifier suffices wherever a reference is required (§4.9). The preceding paragraph forbids compelling a variation that would be false — this forbids compelling the truth, which is the same compulsion. A label states a verified legal name and a category (§4.4, §6.3): a disclosure of a wholly different order from an identifier, and one that principle 8 of §1.2 leaves to the entity alone. The organizational case is the reverse, and deliberately so — an org entity’s label is the accountability check (§10.2), and an organization presenting none has declared nothing anyone can verify.

Where a label is presented, what remains adjustable is three things and no more: whether to present a label or an identifier, which label where the entity holds more than one, and whether to present a discriminator (§4.6). §6.3 fixes the name to the establishing document, §4.4 requires exactly one category, and §4.5 fixes jurisdiction depth to the issuing authority. An entity presenting an attested label in two contexts therefore cannot prevent their correlation by any mechanism in this document, and no future mechanism will change it: the string is the same string. This is the one place in §10 where the protection runs to the holder’s judgement rather than to a constraint on the implementation — which is why the disclosure above is mandatory, and the presentation never is.

A label denotes one identifier, and the two together are the whole of what it presents: a party holding the label resolves it, confirms the binding (§6.2), and reaches nothing else. An entity may hold several labels, and they are no more linkable to one another — or to any identifier of the entity other than the one each denotes — than any two pairwise identifiers are (§10.6). One label of an entity becomes recognizable; the entity does not.

The bare and discriminated forms of one label are the exception: they are one label in two forms, related by inspection rather than by anything a resolver discloses. An entity presenting both to different counterparties should expect them to be recognized as related. §8.2 forbids an implementation from acting on that relation by substituting either form for the other, but nothing conceals it, and an entity wanting to be recognized as two unrelated parties takes two labels rather than two forms of one.

10.6 The label layer and the identifier layer MUST be cryptographically separated. It MUST NOT be possible to derive, correlate, or confirm any relationship between a label an entity uses and any identifier of that entity other than the one that label denotes. That one exception is the whole of the readable layer: a label resolves to it, and a querier holding the label confirms the binding (§6.2). Every other identifier the entity holds stays unreachable from it. This is the single most consequential privacy requirement in this document — without it, the optional readable layer becomes a means of de-anonymizing the identifiers that are private by default.

10.7 A delegated identifier MUST NOT encode its root. An identifier derived from, or nested under, its root’s identifier discloses that root. Delegated identifiers MUST therefore be independent values whose anchor chain is verifiable cryptographically without the root being recoverable from the identifier itself. Exposure would defeat §10.3: every delegate of one root would become linkable to every other, and the root would serve as a correlation key across every context in which that entity operates. Accountability does not require it — the anchor chain establishes that a valid root answers for the delegate, and §3.5.3 proves exactly that fact to a stranger without disclosing which root (§10.9).

Distinctness applies to delegated identifiers as it does to root identifiers. A delegated entity’s identifiers MUST be distinct for each counterparty (§10.3): a device or agent presenting one identifier to every counterparty becomes the correlation key that its root’s pairwise identifiers exist to eliminate, and a stable delegated identifier is a tracking identifier. Whether the root is disclosed is a separate question, governed by the accountability class of that root (§10.2, §3.5.3).

It applies to the chain, not only to its ends. The identifier by which a delegated entity’s anchor chain designates its root MUST be unique to that delegate, at every level of the chain: two delegates of one root MUST NOT designate that root by the same identifier. Were they to do so, the chain itself would become the correlation vector — a party holding two delegates’ chains would learn they share a root, which is exactly the fact §10.3 withholds, and would learn it without ever comparing the delegates’ own identifiers. One root, designated differently to each thing that answers to it, remains one accountable root: uniqueness is a property of enrollment (§2), not of any identifier that denotes it. A representation credential discloses its principal (§3.6.2), and is no exception to this section: the disclosure is made by the grant, deliberately and because it is the credential’s purpose, never by an identifier that encodes a root.

10.8 Categories and jurisdiction are disclosures. A human label states a category and, where present, a jurisdiction. Implementations MUST support holding a credential without using a label that discloses it — a protection that runs to human entities, since a human entity need hold no label at all (§10.5) and its jurisdiction is optional (§4.5). It does not run to org entities, whose material is public by design (§10.2) and whose label is the accountability check itself.

10.9 Identification-on-demand is scoped to accountability, not identity. What a bystander learns from §3.5.3 is that a valid, unrevoked accountable root answers for the machine — never, for a personally owned machine, which human that is. The owner of a humanoid walking beside it is not thereby made discoverable.

10.10 An interaction MUST NOT expose its parties to infrastructure. A transport carrying an interaction between these entities MUST NOT disclose either party’s identifier to any relaying party. Distinct identifiers (§10.3) are not sufficient: infrastructure that records which identifier interacted with which reconstructs the relationships those identifiers were separated to keep apart. The mechanism is outside the scope of this document; the requirement is stated here because it governs how these identifiers may be used.

10.11 Lawful disclosure, and the limits upon it. These schemes govern identifiers and their resolution, not the content of relationships an entity chooses to enter. Nothing here prevents an entity from disclosing information about itself to a counterparty, prevents that counterparty from retaining what it was given, or prevents a court from compelling that counterparty to produce it. A subpoena reaches whoever holds the record, and a party served with one produces what it holds; this specification neither obstructs that nor has anything to say about it.

What the specification does require is that the infrastructure never become a second place to serve. A resolver holds no personal data (§6.1) and no mapping among an entity’s identifiers (§10.3), so process served upon it yields nothing about any person — not by refusal, but because there is nothing to yield. Compelled production is bounded by what a party actually holds, which is why the requirements above are written as incapability rather than as policy: a promise can be overridden by an order, and an absence cannot.

Separately from all of the above, an implementation may be built with a deliberate means of resolving an identifier to a natural person who is not already known to the party resolving it — an escrow key, a recovery path, a registry able to look through its own commitments. This paragraph concerns only that: it does not reach a counterparty decrypting records of its own customer, which is the ordinary operation of a relationship and is governed by the first paragraph. Where such a means exists, no single party may be capable of exercising it alone — not the operator, not a resolver, not an issuer, not a counterparty, and not any accrediting body. Such a capability MUST require the concurrence of parties with distinct interests, at least one of which is independent of every party that would receive the disclosure, and each exercise MUST be recorded such that the subject can later examine what was disclosed, to whom, and on what basis.

None of this weakens §10.3; it is what lets §10.3 survive contact with the world. A system in which one party can unmask on request has protected no one, whether that party is compromised or merely cooperative.

11. IANA considerations

This document requests provisional registration of two URI schemes under the procedures of RFC 7595, §7. Registration templates are provided in the accompanying registration request. In summary:

Promotion of either scheme to permanent status will be requested when this specification is stable and at least one conforming implementation exists (§3.3). Transfer of stewardship to the Consortium proceeds independently and is not a precondition: the change controller is updatable after promotion exactly as before it.

11.1 Implementations during the provisional period

Both schemes are registered provisionally. A provisional registration may be modified or removed (RFC 7595), and this specification will change before any request for permanent status — including, potentially, the grammar of §4. Identifiers minted under this revision carry no guarantee of validity under the next.

Nothing here restricts anyone. Experimentation, prototyping, and review are invited without reservation, and §14.2’s grant is unqualified. What follows is what an implementer should weigh before putting a product in front of users.

An implementation shipped now resolves only into itself. Labels are not unique — two entities may hold the same one (§8.3) — and the identifiers beneath are cryptographic values bearing no relation across implementations. What lends a reference meaning beyond a single operator is a verifier’s ability to judge the method that issued it: method identity reaches a verifier through resolution (§6.1), and the accreditation against which methods are judged publishes with the conformance conditions. Until it does, a verifier outside the issuing implementation has no basis on which to weigh what it is shown, and that implementation’s references work only inside that implementation and nowhere else. An isolated system with a human:// prefix is still isolated, and this specification exists to end that.

No implementation can be evidenced. Every MUST in §§9–10 is a conformance condition (§9), and the means of demonstrating that an implementation meets them publishes with §3.3. An implementation shipped now cannot show that it does — not because it has yet to be tested, but because the test does not yet exist.

The addressing layer is nonetheless free. §14.3 licenses, unconditionally and irrevocably, any claim necessarily infringed by implementing this specification — that grant does not wait on the conformance conditions and is not conditioned on them. What waits is the author’s position on claims beyond what implementing this document requires (§14.3). An implementation built before the conditions exist cannot know whether it will satisfy them, and holds nothing in the interim.

An identifier is a promise to the person who holds it. A promise made on a draft is one you may not be able to keep.

12. Open issues

1. Locality identifiers (§4.5) — confirm GeoNames as the canonical source, and the licensing and stability terms of depending on it.
2. Revocation bounds (§9.6) — the maximum acceptable interval between revocation of an anchor chain and its rejection by verifiers.
3. Action vocabulary — §4.8 deliberately leaves the path vocabulary unspecified here.
4. Category tier registry — the mechanism by which licensing authorities and certifying organizations are accredited, and the published criteria for accreditation, are not yet specified.
5. Conformance conditions (§3.3) — the conditions themselves, and the evidence required to claim them, are reserved to a subsequent revision of this specification.
6. The physical identification exchange (§3.5.3, §9.8) — the presentation format, channel, and range of identification on demand; broadcast cadence and range for non-hailable machines, and carriage within statutory remote-identification regimes; the anti-relay binding of presence claims to local physical circumstances; and the fail-safe behavior of an embodied entity whose anchor chain is revoked.
7. Representation grants (§3.6.2) — the scope vocabulary for representation (media, contexts, counterparties, duration), the disclosure and rendering rules for digital twins, and representation across incapacity and death.
8. Capture-device attestation (§9.10) — the assurance of a presence assertion depends on the capturing device attesting its own integrity, whatever its ownership. What such an attestation must establish, how it is bound to the assertion it accompanies, and what a verifier should conclude when it is absent or weak, is unspecified here.
9. Internationalized labels — the grammar is ASCII-only in this version; whether and how to admit internationalized labels, and under what confusable-detection rules, is deferred.

13. References

Normative — RFC 2119; RFC 3986 (URI Generic Syntax); RFC 4648 (Base16, Base32, and Base64 Data Encodings); RFC 5234 (ABNF); RFC 7595 (URI Scheme Registration); RFC 8174; ISO 3166-1; ISO 3166-2; Unicode TR39 (Security Mechanisms); W3C Decentralized Identifiers (DIDs) v1.0.

Informative — W3C Verifiable Credentials Data Model v2.0; RFC 3552 (Guidelines for Writing RFC Text on Security Considerations); RFC 7401 (Host Identity Protocol); Multibase (origin of the base32 prefix fixed as a literal in §4.1); ISIC Rev. 4; ISCO-08; UN/LOCODE; GeoNames; FAA 14 CFR Part 89 (Remote Identification of Unmanned Aircraft); EU Implementing Regulation (EU) 2019/947; C2PA Content Credentials.

14. License and implementation grant

14.1 The document

This specification is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0): https://creativecommons.org/licenses/by/4.0/

You are free to copy, redistribute, translate, excerpt, and adapt this document for any purpose, including commercially, provided you give appropriate credit to the author, link to the license, and indicate whether changes were made. Attribution should credit Amod Dange as author and cite the canonical location above.

Adapted or translated versions MUST NOT present themselves as the authoritative specification. The authoritative version is the one published at the canonical location and referenced from the IANA URI Schemes registry.

14.2 Implementation

Attribution is a condition on redistributing the document, not on building software. To state this unambiguously, because it is the question every implementer’s counsel will ask:

Implementing this specification requires no permission, no license, no notice, and no royalty. You may build, ship, and sell implementations — open-source or proprietary — without attributing this document in your software, your interfaces, or your marketing. No trademark or naming permission is required to describe an implementation as supporting human:// or org://.

This grant is made under copyright and concerns this document alone. It is not a patent license, confers no patent rights, and grants no permission to practice any claim; the author’s patent position is stated separately (§14.3). Nothing in the CC BY license should be read as restricting implementation, and no such restriction is intended.

14.3 Patents

Implementing this specification requires no patent licence from the author.

Any patent claim the author holds or controls that is necessarily infringed by implementing this specification is licensed to every party, for every purpose, royalty-free, worldwide, and irrevocably. No agreement, notice, registration, or fee is required. The commitment runs with the specification and binds the author’s successors and assigns.

The grant is bounded by its own terms rather than by conditions: it covers what implementing this specification necessarily requires, and no more. Because the scheme is method-agnostic (§6.4), a claim directed at one particular proof-of-personhood method is not necessarily infringed by implementing this specification — building such a method is a separate undertaking from implementing this document, and is not licensed here.

The commitment terminates as to any party that asserts a patent against an implementation of this specification. It grants no trademark, and no right to represent an implementation as certified or endorsed.

Appendix A — Illustrative walkthroughs (non-normative)

This appendix shows the identifiers of §4 doing their work in ordinary situations. It is non-normative: nothing here adds a requirement, and the session, action, and credential details are sketches whose normative homes are outside this document (§1.4). Each walkthrough is chosen to exercise one load-bearing property, cited in place.

A.1 Boarding a robotaxi — the digital medallion

1. A vehicle arrives. Before the passenger boards — the moment of entrustment — their device requests identification (§3.5.3).
2. The vehicle presents proof that verifies offline (§7): entity type device; its operating organization, publicly verifiable (§10.2); a transport-authority category at the Licensed tier, with the operator’s jurisdiction of legal personality and the attesting authority both checkable against the result (§4.5, §6.1); and an anchor chain to a VALID root, unrevoked now.
3. The passenger’s client renders the digital medallion; the passenger boards; identification remains answerable throughout carriage (§3.5.3).
4. Had the operator’s authority been revoked an hour earlier, the chain would already fail within its documented revocation bound — for an embodied entity, a safety parameter, not a preference (§3.5.4) — and the machine would have no valid identity to act under.

A.2 A drone overhead — accountability without surveillance

1. A drone crosses a park, broadcasting its identification at a cadence proportionate to its speed and reach — it cannot be hailed, so it must not wait to be asked (§3.5.3).
2. A bystander’s device verifies the broadcast offline (§7): a valid, unique, unrevoked accountable root answers for this machine, at this moment.
3. The drone is personally owned, so the bystander learns nothing about which human owns it (§10.9) — and unlike statutory remote identification, the broadcast reveals neither the operator’s identity nor their location (§3.5.3). An organization-operated drone would instead disclose its operator (§10.2).
4. A drone broadcasting nothing verifiable is not a lesser participant; it is an unidentified machine, and everything that follows from that follows outside the protocol.

A.3 The call that claims a likeness — presence, representation, or nothing

1. An incoming video call presents the likeness and voice of the user’s employer.
2. The client resolves the session counterparty and determines which of exactly three states holds (§3.6.3).
3. Presence — a fresh live act of the employer, bound to this session, proves they are here, now.
4. Representation — an agent presents an unrevoked grant whose scope covers likeness on video calls, chaining to the employer’s root (§3.6.2). The client renders authorized representative — scope: scheduling, and never renders it as presence.
5. Neither — the chain is absent, revoked, or out of scope. The interaction is a deepfake, whatever its production quality, and the client says so. The user judged no pixels (§9.9): authenticity arrived as a verification result, not a forensic opinion.