Network Working Group B. Morrison Internet-Draft Alter Meridian Pty Ltd Intended status: Informational April 2026 Expires: 13 October 2026 Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems draft-morrison-identity-pronouns-00 Abstract This document defines an identity pronoun grammar as a reference axis orthogonal to the ~handle identity tier taxonomy defined in [MCPDNS] and [IDCOMMITS]. A pronoun is a session-scoped reference that resolves client-side to a concrete handle using local session state before any cryptographic, DNS, or federation operation. The entity- class taxonomy (Sovereign, Bot, Instrument) is unchanged; this specification introduces Absolute vs Pronoun as an orthogonal axis. A pronoun MUST NOT appear in a capability token, in a DNS record, in an Accord signature, or in any inter-organisational protocol payload. The reference implementation defines a single Wave-1 pronoun, ~org, that resolves to the concrete handle of the organisation bound to the caller's current session. An appendix defines a relative-path pronoun grammar (e.g. ~./architect, ~../weaver) as a non-normative design surface for future work. The mechanism is provider-neutral, introduces no new cryptographic primitive, and imposes zero new load on DNS, capability-token issuers, or federated resolvers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 October 2026. Morrison Expires 13 October 2026 [Page 1] Internet-Draft Identity Pronouns April 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Status of This Memo . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 4. The Reference Axis . . . . . . . . . . . . . . . . . . . . . 4 4.1. Two Orthogonal Axes . . . . . . . . . . . . . . . . . . . 4 4.2. Wire Invariant . . . . . . . . . . . . . . . . . . . . . 5 4.3. Resolution Algorithm . . . . . . . . . . . . . . . . . . 6 5. The ~org Pronoun (Wave 1) . . . . . . . . . . . . . . . . . . 7 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Session Binding . . . . . . . . . . . . . . . . . . . . . 7 5.3. Resolution Failures . . . . . . . . . . . . . . . . . . . 7 5.4. Example (non-normative) . . . . . . . . . . . . . . . . . 8 6. Pronoun Lexicon Extensibility . . . . . . . . . . . . . . . . 8 6.1. Per-Client Lexicon . . . . . . . . . . . . . . . . . . . 8 6.2. Per-Org Lexicon (Future Work) . . . . . . . . . . . . . . 8 7. Relative-Path Pronoun Grammar (Appendix, Non-Normative) . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9.1. Pronoun Spoofing . . . . . . . . . . . . . . . . . . . . 10 9.2. Pronoun Leakage . . . . . . . . . . . . . . . . . . . . . 10 9.3. Binding Freshness . . . . . . . . . . . . . . . . . . . . 10 9.4. Cross-Tenant Confusion . . . . . . . . . . . . . . . . . 10 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Morrison Expires 13 October 2026 [Page 2] Internet-Draft Identity Pronouns April 2026 1. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 2. Introduction The ~handle identity primitive defined in [MCPDNS] binds a textual identifier to a cryptographic principal via DNS TXT records under an _alter. prefix. The tier taxonomy subsequently locked in [IDCOMMITS] partitions handles into three parser-enforced entity classes -- Sovereign, Bot, and Instrument -- each with distinct capabilities and invariants. The three-tier taxonomy answers the question: _what kind of thing does this handle bind to?_ This document answers a second, orthogonal question: _how is the handle referenced?_ A reference may be absolute (a literal handle transmitted on the wire) or pronominal (a session-scoped reference resolved by the client before transmission). Every pronoun resolves to one of the three entity classes at evaluation time; the entity taxonomy is unchanged. The motivating use case is multi-organisational identity. A human agent who is a member of two organisations requires a pronoun that resolves to "the organisation bound to my current session" without hard-coding either organisation's concrete handle into the agent's command surface. A shell user relies on the same pattern when ~ [POSIX-TILDE] resolves to $HOME for the invoking user rather than any specific directory path. Git [GIT-REVISIONS] relies on HEAD and @{upstream} as first-class reflexive references. CSS [CSS-SELECTORS-4] relies on :root and :host as grammar-level contextual references. Kubernetes [K8S-SUBJECTACCESSREVIEW] relies on :self as a protocol-level reflexive subject. Morrison Expires 13 October 2026 [Page 3] Internet-Draft Identity Pronouns April 2026 Each of these precedents shares three properties. The pronoun is (1) first-class in the surface grammar, (2) resolved before the underlying protocol sees it, and (3) absent from any payload that crosses a trust boundary. This specification adopts the same three properties for the ~handle system. 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined for the purposes of this document: * *Handle.* A textual identifier of the form ~ followed by a label, as defined in [MCPDNS]. * *Absolute handle.* A handle whose textual form is identical to the handle it identifies (e.g. ~blake, ~truealter.com). * *Pronoun.* A handle whose textual form is a reserved reference expression that resolves to a concrete absolute handle via a defined resolution algorithm (e.g. ~org, ~me). * *Concrete handle.* The absolute handle produced by resolving a pronoun; in contrast to the pronoun's surface form. * *Resolution.* The operation of replacing a pronoun with its concrete handle in a given context. * *Session state.* The set of bindings available to a client at the time of resolution, including but not limited to the caller's sovereign handle, the caller's currently-bound organisation, and any pronoun lexicon loaded by the caller's client. * *Wire.* Any transport boundary crossed by an identity-bearing payload, including capability tokens, DNS records, MCP tool invocations, HTTP requests to federated peers, and signatures attached to Accord documents. 4. The Reference Axis 4.1. Two Orthogonal Axes The ~handle identity system has two orthogonal axes. The first axis is *entity class*, defined in [IDCOMMITS]: Morrison Expires 13 October 2026 [Page 4] Internet-Draft Identity Pronouns April 2026 Sovereign | Bot | Instrument The second axis, defined by this document, is *reference type*: Absolute | Pronoun Every handle is a point in the two-dimensional space defined by these axes. An Absolute Sovereign is a concrete handle such as ~blake. A Pronoun Sovereign is a reference such as ~org that resolves to a concrete Sovereign handle at evaluation time. An Absolute Bot is ~dependabot.bot. A Pronoun Bot is a reference such as ~my- runtime.bot (non-normative example) that resolves to the concrete Bot handle of the caller's currently-active runtime daemon. The two axes are orthogonal: a pronoun's entity class is a property of the concrete handle produced by resolution, not of the pronoun itself. 4.2. Wire Invariant A pronoun MUST NOT appear in a typed handle field of any structured payload that crosses a protocol trust boundary. Before any of the following operations, a pronoun appearing in a handle field MUST be resolved to its concrete handle: 1. Any DNS query or DNS record publication under the _alter. prefix or any other DNS label used for ~handle resolution. 2. Issuance or verification of any capability token whose subject, audience, or resource identifier references a handle. 3. Any cryptographic signing or verification operation over an identity-bearing payload, including but not limited to Accord documents [IDACCORD], Identity-Attributed commit trailers [IDCOMMITS], attestation statements, and IdentityRank claims. 4. Any MCP tool invocation, HTTP request to a federated peer's .well-known/alter endpoint, or other protocol payload in which a handle appears as a typed field. 5. Any write to an append-only identity log, continuous identity- field record, or Signed Tree Head anchor. 6. Any on-chain reference, smart-contract call, or blockchain anchoring operation (e.g. x402 micropayment routing) that encodes a handle as a contract parameter. Morrison Expires 13 October 2026 [Page 5] Internet-Draft Identity Pronouns April 2026 This enumeration is non-exhaustive. The governing principle is that a pronoun is a property of the caller's session context and MUST NOT be transmitted to any principal who does not share that session context. The Wire Invariant applies to handle fields in structured payloads. A handle field is a field typed as "handle" in a payload schema or a positional argument documented as carrying a handle. The invariant does NOT apply to natural-language content -- for example, the body of an alter-to-alter message, a user prompt, or a documentation string -- that incidentally contains a pronoun token. A client MUST NOT rewrite pronoun tokens appearing inside free-text content; such content is conveyed verbatim and a remote reader is responsible for recognising that a pronoun in free text is scoped to the author's session, not the reader's. A client MAY surface a usability warning when free-text content contains pronoun tokens, but MUST NOT transform the content. This invariant is the architectural rationale for defining pronouns in this document rather than extending the entity-class taxonomy. Pronouns are a property of the client's presentation layer; concrete handles are the property of the protocol. A conformant implementation MUST reject any payload received over the wire in which a pronoun appears in a typed handle field. This rejection is a category error analogous to the cross-tier rejection defined in [IDCOMMITS]. 4.3. Resolution Algorithm Resolution is performed by the client immediately prior to the first operation listed in the Wire Invariant above. The resolution algorithm proceeds in three phases. Phase 1 is lexicon lookup. The client maintains a pronoun lexicon mapping reserved textual forms to resolver functions. If the handle's textual form does not match any entry in the loaded lexicon, the handle is treated as absolute and no further resolution is performed. Phase 2 is context binding. The resolver function is invoked with the current session state. Session state MUST include at minimum the caller's sovereign handle; it MAY include the caller's currently- bound organisation, the caller's currently-held seats, the current thread identifier, and any other context the pronoun's resolver requires. Morrison Expires 13 October 2026 [Page 6] Internet-Draft Identity Pronouns April 2026 Phase 3 is substitution. The resolver returns a concrete handle or an error. On success, the pronoun is replaced with the concrete handle in the payload about to be transmitted. On error, the operation that triggered resolution MUST be aborted; the pronoun MUST NOT be transmitted unresolved as a fallback. A conformant resolver MUST be deterministic within a single session: two successive resolutions of the same pronoun within the same session state MUST yield the same concrete handle. 5. The ~org Pronoun (Wave 1) 5.1. Definition ~org is a Sovereign-class pronoun that resolves to the concrete sovereign handle of the organisation currently bound to the caller's session. 5.2. Session Binding The session state that binds ~org is established at authentication time (typically by a command of the form alter login or equivalent). The binding is recorded in a session-state artefact local to the caller's environment -- on reference implementations, a file at the path $HOME/.config/alter/session.json is RECOMMENDED -- and MUST contain at least the field current_org whose value is the concrete sovereign handle of the bound organisation. A client MAY provide a switch command (e.g. alter switch ) that rewrites current_org without requiring re-authentication, provided the caller is already a verified member of the target organisation. 5.3. Resolution Failures ~org resolution MUST fail, and the triggering operation MUST be aborted, if any of the following hold: * The session-state artefact is absent or unreadable. * The current_org field is absent, empty, or malformed. * The caller is no longer a verified member of the bound organisation (e.g. revocation has occurred since session start). A resolution failure is distinct from an absolute handle referencing a non-existent organisation. The latter fails at protocol layer; the former fails at client layer before any wire operation. Morrison Expires 13 October 2026 [Page 7] Internet-Draft Identity Pronouns April 2026 5.4. Example (non-normative) A member bound to ~alter via alter login ~alter invokes a messaging command: alter message send --to ~org --body "what is due this week?" The client resolves ~org to ~alter by reading current_org from session state. The outbound capability-token subject field carries ~alter; the pronoun ~org does not appear on the wire. The same member subsequently invokes alter switch ~pak-ho-co (an organisation they are a member of via a separate invitation). The next invocation of the same command resolves ~org to ~pak-ho-co instead. Neither invocation requires the member to retype the concrete handle. 6. Pronoun Lexicon Extensibility 6.1. Per-Client Lexicon An implementation MAY load a pronoun lexicon from any source trusted by the operator. The reference implementation ships a minimal lexicon containing ~org only. Additional pronouns MAY be added by the client without coordination with any other party, provided the Wire Invariant is preserved. 6.2. Per-Org Lexicon (Future Work) A future revision of this document is expected to define a DNS-based mechanism by which an organisation MAY publish a pronoun lexicon as part of its _alter. record, enabling members of that organisation to load org-specific pronouns (e.g. ~weaver resolving to the current holder of the Weaver seat within that org). Such pronouns MUST obey the Wire Invariant: the DNS record carries the lexicon metadata, not resolved values, and resolution remains a client-side operation. This extension is out of scope for the present document. The protocol-version constant defined by [MCPDNS] is not incremented. 7. Relative-Path Pronoun Grammar (Appendix, Non-Normative) This appendix describes a relative-path pronoun grammar as a design surface for future work. The grammar is non-normative in the present document; implementations SHOULD NOT emit these forms in Wave 1. The grammar borrows from POSIX path semantics [POSIX-TILDE]: Morrison Expires 13 October 2026 [Page 8] Internet-Draft Identity Pronouns April 2026 * ~./