Skip to main content

The 'alter' URI Scheme for Dispatchable ~handle References
draft-morrison-alter-uri-scheme-05

Document Type Active Internet-Draft (individual)
Author Blake Morrison
Last updated 2026-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-morrison-alter-uri-scheme-05
Network Working Group                                        B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Informational                           21 October 2026
Expires: 24 April 2027

       The 'alter' URI Scheme for Dispatchable ~handle References
                   draft-morrison-alter-uri-scheme-05

Abstract

   This document defines the alter URI scheme as a dispatchable
   reference syntax for ~handle identity references published in the DNS
   records defined in the companion specification for discovering Model
   Context Protocol servers through DNS TXT records.  An alter: URI
   binds a textual ~handle reference to a resolution and verification
   procedure that retrieves the handle's envelope from a publishing
   zone, validates the envelope's signature chain, and dispatches the
   result to an operating-system URI handler.  The reference may be
   scoped to an organisation, narrowed to a named facet of the identity,
   and addressed to a typed action surface.  The scheme is the
   addressing form of the ~handle@org:facet/action reference; its
   resolution semantics are those of that companion specification,
   reused without modification.

   The scheme is provider-neutral and introduces no new cryptographic
   primitive.  A handler given an alter: URI verifies the handle's
   envelope before acting on it, and where the URI addresses an action,
   verification precedes any side effect.  IANA provisionally registered
   the alter scheme under Section 4 of RFC 7595 on 5 October 2026.

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 24 April 2027.

Morrison                  Expires 24 April 2027                 [Page 1]
Internet-Draft              alter URI Scheme                October 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Scheme Definition . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Scheme Name . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Status  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  URI Scheme Syntax . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Scheme Semantics  . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Encoding Considerations . . . . . . . . . . . . . . . . .  10
     3.6.  Applications and Protocols That Use This Scheme . . . . .  10
     3.7.  Interoperability Considerations . . . . . . . . . . . . .  10
     3.8.  Context Artefact Type . . . . . . . . . . . . . . . . . .  11
     3.9.  Artefact Type Genus Membership  . . . . . . . . . . . . .  12
     3.10. Security Considerations . . . . . . . . . . . . . . . . .  12
     3.11. Author / Change Controller  . . . . . . . . . . . . . . .  12
     3.12. References  . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Operating-System Handler Registration . . . . . . . . . . . .  13
     4.1.  Linux desktops  . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  macOS . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Windows . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.4.  Android . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.5.  iOS . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Addressing Examples . . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     6.1.  Verification Mandate  . . . . . . . . . . . . . . . . . .  14
     6.2.  Action-Address Confusion  . . . . . . . . . . . . . . . .  14
     6.3.  Context Reference Confusion . . . . . . . . . . . . . . .  15
     6.4.  Handler Substitution  . . . . . . . . . . . . . . . . . .  15
     6.5.  Path-Component Privacy  . . . . . . . . . . . . . . . . .  15
     6.6.  Ref-Segment Traversal . . . . . . . . . . . . . . . . . .  16
     6.7.  Cross-Scheme Confusion  . . . . . . . . . . . . . . . . .  16
     6.8.  Form Confusion  . . . . . . . . . . . . . . . . . . . . .  16
     6.9.  Handle-Domain Confusion . . . . . . . . . . . . . . . . .  17
     6.10. IRI Considerations  . . . . . . . . . . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17

Morrison                  Expires 24 April 2027                 [Page 2]
Internet-Draft              alter URI Scheme                October 2026

   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  18
   10. Informative References  . . . . . . . . . . . . . . . . . . .  19
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  20
     A.1.  draft-morrison-alter-uri-scheme-05  . . . . . . . . . . .  20
     A.2.  draft-morrison-alter-uri-scheme-04  . . . . . . . . . . .  20
     A.3.  draft-morrison-alter-uri-scheme-03  . . . . . . . . . . .  22
     A.4.  draft-morrison-alter-uri-scheme-02  . . . . . . . . . . .  23
     A.5.  draft-morrison-alter-uri-scheme-01  . . . . . . . . . . .  23
     A.6.  draft-morrison-alter-uri-scheme-00  . . . . . . . . . . .  23
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The ~handle identity primitive defined in [MCPDNS] binds a textual
   identifier of the Sovereign or Bot tier ([IDCOMMITS] Section 3) to a
   cryptographic principal published under an _alter.  DNS TXT record.
   An Instrument-tier handle, such as ~cc-example-model, is not an
   independent handle: it names an instrument whose acts are attributed
   to the Sovereign that operates it, and it has no envelope of its own
   ([MCPDNS] Section 2).  A handle reference written in running text,
   such as ~alice or ~example.com, is interpretable to a human reader
   but is not, by itself, a dispatchable reference for a machine.

   This document defines the alter URI scheme as the dispatchable form
   of a handle reference.  An alter: URI binds a ~handle to the
   resolution procedure of [MCPDNS] and to a URI handler registered with
   the host operating system.  It carries three optional addressing
   components, an organisational scope, a facet, and an action-path.  A
   handler that receives alter:~alice retrieves and verifies the
   envelope, then decides what to do with it (open an inbox, show a
   profile card, initiate an Accord ceremony per [IDACCORD], dispatch to
   a per-surface MCP tool).

   A reference can also name an organisation, a facet of the identity,
   and an action surface under that facet.  For example,
   alter:~carol@acme.example:security/verify names the verify action
   under the security facet of ~carol at acme.example, in one string.
   Every component beyond the handle is OPTIONAL; a bare alter:~alice
   remains valid.

Morrison                  Expires 24 April 2027                 [Page 3]
Internet-Draft              alter URI Scheme                October 2026

   This document specifies the addressing syntax, the dispatch and
   verification obligations of a handler, and the operating-system
   registration entries a handler installs.  It does not specify the
   resolution semantics of any facet or action surface.  What a given
   facet or action means, and how a resolver computes its answer, are
   owned by the specification that defines that surface.  This document
   also carries the registration template submitted to IANA under
   [RFC7595] Section 7.2; the DNS record format is specified in
   [MCPDNS].

1.1.  Requirements Language

   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.

2.  Terminology

   ~handle  A textual identity reference defined in [MCPDNS] and tiered
      in [IDCOMMITS].  Handles begin with the tilde character U+007E.

   Envelope  The signed identity record retrieved from the
      _alter.<domain> DNS TXT record of the publishing zone, as
      specified in [MCPDNS] Section 7.

   Organisational scope  An optional DNS-named organisation qualifying a
      handle, written after an @ separator, e.g. ~carol@acme.example.
      The scope identifies the publishing zone under which the handle's
      envelope is resolved.  Because a handle carries no zone of its
      own, a reference with no scope names no zone (Section 3.4). org-
      scope selects the publishing zone consulted in the resolution
      procedure of Section 3.4; it carries no claim about which context,
      tenancy, or organisational capacity the presenting principal is
      presently acting under.  A resolver, facet, or action-path
      definition MUST NOT infer the principal's acting context from the
      presence, absence, or value of org-scope.  Where a reference needs
      to carry acting context, it does so via a context artefact
      reference (see Context Artefact Type below) or via a facet or
      action-path defined for that purpose by the surface that owns it,
      never via org-scope.

   Facet  An optional named aspect of an identity, written after a :

Morrison                  Expires 24 April 2027                 [Page 4]
Internet-Draft              alter URI Scheme                October 2026

      separator, e.g. :security.  A facet narrows a reference to one
      addressable face of the identity.  What a facet denotes, and how a
      resolver answers it, are defined by the surface specification that
      owns the facet, not by this document.  An identity-pronoun
      reference axis [IDPRONOUNS] is one example of the kind of
      specification that could own such a facet.

   Action-path  An optional typed surface addressed under a handle (and
      facet, if present), expressed as the path component of the URI,
      e.g. verify, decisions/123, billing/invoices.  An action-path
      names an operation or resource surface; its semantics are owned by
      the specification that defines it.

   Artefact type  A lowercase-alphabetic label identifying a member of a
      typed artefact genus, carried as the first path segment of an
      artefact-ref-form URI, e.g. context in alter:context/9f2a-
      freelance-b.  An artefact type names a member of a genus whose
      extent is owned by the specification defining that genus, not by
      this document; this document defines the shape of the reference,
      not the genus it addresses.

   Artefact reference  An opaque reference to one member of the genus
      named by an artefact type, carried as the second path segment of
      an artefact-ref-form URI, e.g. 9f2a-freelance-b in
      alter:context/9f2a-freelance-b.  What an artefact reference
      denotes, and how a resolver dereferences it, are defined by the
      surface specification that owns the artefact type, not by this
      document.

   Handler  An operating-system component registered to receive alter:
      URIs and dispatch to a resolver.  Examples include xdg-mime
      associations [XDG-MIME] on Linux, LaunchServices URL handlers
      [LSHANDLERS] on macOS and iOS, registry entries under HKCR on
      Windows, and intent filters on Android.

3.  Scheme Definition

3.1.  Scheme Name

   alter

3.2.  Status

   Provisional.  IANA provisionally registered the alter scheme under
   [RFC7595] Section 4 on 5 October 2026.  Permanent registration,
   against the requirements of [RFC7595] Section 3, is the intended
   upgrade path once the scheme specification stabilises.

Morrison                  Expires 24 April 2027                 [Page 5]
Internet-Draft              alter URI Scheme                October 2026

3.3.  URI Scheme Syntax

   The alter URI scheme's generic syntax conforms to [RFC3986].  The
   scheme carries two disjoint reference forms under one scheme name.
   The grammar uses the ABNF of [RFC5234].  ALPHA, DIGIT and HEXDIG are
   its core rules, and unreserved, pct-encoded, sub-delims, pchar, query
   and fragment repeat the productions of [RFC3986].

 alter-URI          = "alter:" ( handle-ref-form
                                 / artefact-ref-form )

 handle-ref-form     = handle-ref [ "@" org-scope ]
                         [ ":" facet ] [ "/" action-path ]
                         [ "?" query ] [ "#" fragment ]

 artefact-ref-form   = artefact-type [ "/" artefact-ref ]
                         [ "?" query ] [ "#" fragment ]

 handle-ref   = "~" handle-name

 handle-name  = sovereign-name / bot-name / instrument-name

 sovereign-name
              = ALPHA *( ALPHA / DIGIT / "-" / "." )
                  ; Sovereign tier.

 bot-name     = ALPHA *( ALPHA / DIGIT / "-" / "." ) ".bot"

 instrument-name
              = "cc-" 1*( ALPHA / DIGIT / "-" / "." )
                  ; Instrument tier.

 artefact-type
              = 1*LOWER
                  ; the artefact genus member name; lowercase only

 artefact-ref = ref-segment *( "/" ref-segment )
                  ; opaque within the genus named by artefact-type

 ref-segment  = 1*( unreserved / pct-encoded )
                  ; "~" is unreserved in RFC 3986 (its section 2.3), and
                  ; any other octet is available via pct-encoded.
                  ; A ref-segment MUST NOT be "." or "..", and cannot
                  ; be empty, so "//" and a trailing "/" are both
                  ; malformed.  See Ref-Segment Traversal under
                  ; Security Considerations

 org-scope    = domain-label *( "." domain-label )

Morrison                  Expires 24 April 2027                 [Page 6]
Internet-Draft              alter URI Scheme                October 2026

                  ; the organisational zone qualifying the handle

 domain-label = ALPHA / ( ALPHA *( ALPHA / DIGIT / "-" )
                          ( ALPHA / DIGIT ) )

 facet        = facet-label *( "." facet-label )
                  ; a named aspect of the identity surface

 facet-label  = ALPHA *( ALPHA / DIGIT / "-" )

 action-path  = action-segment *( "/" action-segment )
 action-segment
              = 1*( unreserved / pct-encoded / sub-delims
                    / ":" / "@" )

 query        = *( pchar / "/" / "?" )
 fragment     = *( pchar / "/" / "?" )

 pchar        = unreserved / pct-encoded / sub-delims / ":" / "@"
 unreserved   = ALPHA / DIGIT / "-" / "." / "_" / "~"
 pct-encoded  = "%" HEXDIG HEXDIG
 sub-delims   = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="
 LOWER        = %x61-7A
                  ; a-z

   The two alternatives of alter-URI are unambiguous because they are
   discriminated by the single octet immediately following the scheme
   separator alter:.  U+007E TILDE (~) introduces a handle-ref-form
   reference; a lowercase ALPHA introduces an artefact-ref-form
   reference; no other leading octet is valid, and a URI beginning with
   any other octet MUST be rejected.  The artefact-type is restricted to
   1*LOWER because the tilde character is reserved as the handle prefix
   under this scheme and MUST NOT begin an artefact-type.  A parser that
   inspects only this first octet can determine which grammar governs
   the remainder of the URI without backtracking.

   The handle-name ABNF carries the three tiers of [IDCOMMITS] Section 3
   using the lexical markers of [MCPDNS] Section 2, a trailing .bot for
   the Bot tier and a leading cc- for the Instrument tier, without
   restating tier-level invariants; an alter: URI carries a single
   handle and the parser determines the tier from the lexical form.

   The four identity-bearing components of handle-ref-form are parsed
   left to right and each is bounded by its introducing delimiter: the
   handle follows the scheme separator, an @ introduces the
   organisational scope, the first : after the handle (or scope)
   introduces the facet, and the first / introduces the action-path.  A

Morrison                  Expires 24 April 2027                 [Page 7]
Internet-Draft              alter URI Scheme                October 2026

   : appearing after the first / is a literal action-segment character,
   not a facet delimiter, because the facet, if present, is fully
   consumed before any /.  Likewise an @ appearing after the first / is
   a literal action-segment character and never introduces an org-scope,
   since an org-scope can only follow handle-ref directly.  Every
   component after handle-ref is OPTIONAL and any combination MAY be
   omitted.

   The host-component slot of a generic URI is not used.  All identity-
   bearing material is carried in the path-like productions immediately
   after the scheme separator; the @ in org-scope is a component
   delimiter within that material and MUST NOT be read as the userinfo @
   of an [RFC3986] authority.

   This document admits one member to the artefact-type genus, context
   (Section 3.8).  Any other member is admitted by the specification
   that defines what it addresses (Section 3.9).  The genus is a set of
   reference shapes and governs no storage or transport format.

3.4.  Scheme Semantics

   Operations on an alter: URI in handle-ref-form are retrieval-and-
   verify by default.  Submitting an alter: URI in handle-ref-form to a
   handler MUST perform the resolution and verification procedure
   specified in [MCPDNS] Section 12.3 before any content, directive, or
   action derived from the resulting envelope is acted upon.
   Specifically, the handler MUST:

   1.  Parse the URI per the ABNF above, isolating the handle, and any
       organisational scope, facet, and action-path.

   2.  Take the publishing zone from org-scope.  Where org-scope is
       absent, the reference names no zone, and the handler proceeds
       only if it holds an association between the handle and a zone
       established out of band; otherwise the reference is unresolvable.
       A zone is never derived from the spelling of the handle
       (Section 6.9).

   3.  Retrieve and DNSSEC-validate [RFC4033] the _alter.<zone> TXT
       record, as [MCPDNS] Section 12.3 specifies.

   4.  Select the record whose handle matches, and verify the envelope
       signature against the published Ed25519 key, per [MCPDNS]
       Section 12.3.  An envelope that procedure does not treat as
       verified is unverified.

Morrison                  Expires 24 April 2027                 [Page 8]
Internet-Draft              alter URI Scheme                October 2026

   5.  If a facet or action-path is present, forward it verbatim, with
       the verified handle, as the specification that defines that facet
       or action surface directs.  The envelope names no resolver.  The
       fields of [MCPDNS] Section 7 carry no endpoint, and the procedure
       of [MCPDNS] Section 12.3 recognises the handle without reading a
       facet or action-path.

   Envelope retrieval in Step 3 is a DNS query.  [MCPDNS] defines no
   other surface from which an envelope is retrieved, and neither does
   this document; where the _alter.<zone> TXT record is absent, the
   reference is unresolvable.

   An Instrument-tier handle names an instrument whose acts are
   attributed to the Sovereign that operates it.  It is not an
   independent handle and has no envelope of its own ([MCPDNS]
   Section 2; [MCPDNS] Section 7.3.2).  A handler MUST NOT treat a
   handle-ref-form reference whose handle is Instrument-tier as naming
   an independent principal: it MUST NOT accept a record published for
   that handle as the instrument's envelope, and MUST NOT dispatch a
   facet or action-path under it on the instrument's authority.
   Authority for anything done with an instrument is the operating
   Sovereign's, verified under the Sovereign's own handle.

   The facet and action-path are addressing information only.  This
   document does not define what any facet denotes, how a resolver
   answers an action, or what value a dereference yields; the surface
   specification that defines the facet or action owns those semantics.
   A conforming handler treats the facet and action-path as opaque,
   verified-then-forwarded tokens.

   Where an action-path names an operation with a side effect, the
   verification of Step 4 is a precondition to that side effect:
   handlers MUST NOT perform, initiate, or authorise any action
   addressed by an alter: URI until the envelope has been retrieved and
   verified.  Handlers SHOULD treat any verification failure as a hard
   error and SHOULD NOT fall back to unverified retrieval or to
   executing the addressed action.

Morrison                  Expires 24 April 2027                 [Page 9]
Internet-Draft              alter URI Scheme                October 2026

   An alter: URI in artefact-ref-form addresses a typed artefact, not a
   ~handle.  The resolution procedure of Steps 1-5 above is defined
   entirely in terms of DNS zone resolution for a handle and does not
   apply to it.  This document does not define how an artefact-type is
   resolved to a genus, how an artefact-ref is dereferenced to content,
   or what a handler does upon receiving one.  The specification that
   defines the artefact genus named by artefact-type owns those
   semantics, as a surface specification owns facet and action-path
   semantics.  A conforming handler that receives an artefact-ref-form
   URI and has no such specification registered MUST treat it as
   unresolvable and MUST NOT attempt handle resolution against it.

3.5.  Encoding Considerations

   alter URIs are ASCII per [RFC3986]; characters outside the unreserved
   set MUST be percent-encoded.  The IRI form per [RFC3987] is supported
   for action-paths that contain non-ASCII characters; the handle-ref,
   org-scope, and facet productions MUST be ASCII, as the DNS labels of
   [MCPDNS] are.  The tilde character U+007E is reserved as the handle
   prefix and is treated as a literal, not as an unreserved-character
   escape.

3.6.  Applications and Protocols That Use This Scheme

   A command-line client by the present author accepts alter: URIs
   supplied to it as input.  It does not register as an operating-system
   handler for the scheme and does not run the resolution procedure of
   Section 3.4.  Any agent runtime, client, or operating-system
   component that resolves ~handle references can register a handler for
   the scheme.

3.7.  Interoperability Considerations

   Each target platform has its own URI handler registry:

   *  Linux desktops: xdg-mime associations [XDG-MIME].

   *  macOS: CFBundleURLSchemes entries in an application's Info.plist
      [LSHANDLERS].

   *  Windows: HKEY_CLASSES_ROOT\alter with URL Protocol and
      shell\open\command subkeys.

   *  Android: <intent-filter> with <data android:scheme="alter">.

   *  iOS: CFBundleURLSchemes entries in an application's Info.plist
      [LSHANDLERS].

Morrison                  Expires 24 April 2027                [Page 10]
Internet-Draft              alter URI Scheme                October 2026

   Where multiple applications register a handler for alter:, the
   operating system's default-application policy applies.  No special
   arbitration mechanism is defined by this document.

   Browsers MAY treat alter: URIs as opaque external schemes and
   delegate dispatch to the operating-system handler.  Clients SHOULD
   NOT attempt direct retrieval of alter: URIs over HTTP; the resolution
   procedure of [MCPDNS] Section 12.3 retrieves the envelope by a DNS
   query and defines no HTTP retrieval of it.

   The alter scheme does not displace any existing scheme and does not
   contradict the path-handling rules of [RFC3986].  It coexists with
   https:, mailto:, and other schemes that an operating system may
   dispatch on the same surface.

3.8.  Context Artefact Type

   context is a member of the artefact-type genus (Section 3.3), naming
   the reference shape for a context artefact.  A context artefact is an
   object the presenting principal holds, distinct from an
   organisational scope or a facet.  This document specifies the
   reference shape only; it assigns no meaning to what a context
   artefact carries, in the same way it assigns no meaning to an
   artefact reference generally.

   context-ref-form      = "context" "/" context-ref
                              [ "?" query ] [ "#" fragment ]

   context-ref            = personal-context / opaque-context-ref

   personal-context       = "personal"
                              ; RESERVED.  Denotes the presenting
                              ; principal's own organisation-free
                              ; default context, as a positive,
                              ; present value rather than the
                              ; absence of one.

   opaque-context-ref     = 1*( ALPHA / DIGIT / "." / "_" / "-" )
                              ; opaque within the context genus,
                              ; using a character class that itself
                              ; excludes "~".  MUST NOT lexically
                              ; embed a handle-name or a domain-
                              ; label; a reference that embeds
                              ; either is non-conforming.

   context-ref-form is artefact-ref-form with artefact-type = "context";
   it introduces no third alternative to alter-URI and no change to the
   discriminator rule of Section 3.3.  Worked forms: alter:context/

Morrison                  Expires 24 April 2027                [Page 11]
Internet-Draft              alter URI Scheme                October 2026

   personal, alter:context/9f2a-freelance-b.  The RESERVED personal
   literal is the one exception to full opacity within this genus:
   because it is identical across every principal rather than an opaque
   per-context identifier, resolving it never distinguishes one
   principal's personal context from another's, and it reveals only that
   a personal-context resolution was attempted.

   A context artefact reference is an address authored by its holder,
   naming which context artefact is meant.  Determining which context is
   presently acting for a given session or request is out of scope, as
   the resolution meaning of a facet or an action-path is; see Context
   Reference Confusion in Section 6.

3.9.  Artefact Type Genus Membership

   Beyond context (Section 3.8), this document admits no member to the
   artefact-type genus and establishes no registry of artefact-type
   names.  A specification that defines a kind of artefact MAY admit a
   member by naming its artefact-type, stating what an artefact-ref
   under it denotes and how one is dereferenced, and stating any sub-
   grammar it imposes on artefact-ref, following the pattern of
   Section 3.8.  A member that needs no sub-grammar conforms to
   artefact-ref-form as specified, with artefact-ref opaque within the
   member.

   artefact-ref is a sequence of ref-segments so that a member can place
   a scoping name ahead of the reference it scopes, for example
   alter:example/scope-a/item-7, without folding the two into one
   segment that only the emitter could read.

3.10.  Security Considerations

   See Section 6 below.

3.11.  Author / Change Controller

   Blake Morrison, Alter Meridian Pty Ltd, blake@truealter.com.  Change
   control transfers to the IETF if this scheme is later specified by an
   IETF Stream document.

3.12.  References

   [MCPDNS], [IDCOMMITS], [RFC3986], [RFC7595].

Morrison                  Expires 24 April 2027                [Page 12]
Internet-Draft              alter URI Scheme                October 2026

4.  Operating-System Handler Registration

   The following non-normative subsections sketch the platform- specific
   registration entries that a conforming handler installs.
   Implementations are responsible for the platform-specific syntax;
   this document does not prescribe handler binaries or invocation
   shapes.

4.1.  Linux desktops

   A .desktop file with MimeType=x-scheme-handler/alter; and a Exec=
   line invoking the platform resolver.

4.2.  macOS

   A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") and a
   CFBundleURLName of Identity Handle Reference in the application's
   Info.plist.

4.3.  Windows

   Registry entries under HKEY_CLASSES_ROOT\alter:

   *  A default value of URL:Identity Handle Reference.

   *  A URL Protocol value of empty string.

   *  A shell\open\command subkey with the handler invocation.

4.4.  Android

   An <intent-filter> declaring <data android:scheme="alter"/> on an
   Activity capable of performing the resolution procedure of [MCPDNS]
   Section 12.3.

4.5.  iOS

   A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") in the
   application's Info.plist [LSHANDLERS].  Associated domains and
   universal links serve https: URLs and do not register a custom
   scheme.  An application that only opens alter: URIs, and handles
   none, lists alter under LSApplicationQueriesSchemes if it needs to
   test whether a handler is installed.

Morrison                  Expires 24 April 2027                [Page 13]
Internet-Draft              alter URI Scheme                October 2026

5.  Addressing Examples

   The following non-normative examples illustrate the addressing
   syntax.  Facet and action semantics are out of scope; each surface is
   defined by the specification that owns it.

   alter:~alice
   alter:~example.com/decisions/123
   alter:~bob/inbox
   alter:~carol@acme.example
   alter:~carol@acme.example:security
   alter:~carol@acme.example:security/verify
   alter:~example.com:billing/invoices

   The first form addresses an envelope; the second and third address
   action surfaces under an envelope; the fourth scopes a handle to an
   organisation; the fifth adds a facet; the sixth adds a typed action
   under that facet; the seventh addresses a facet-scoped surface.  The
   first three, and the seventh, carry no org-scope.  A handler resolves
   them only through a zone association held out of band (Section 3.4).
   No example addresses an Instrument-tier handle, for the reason given
   in Section 3.4.

6.  Security Considerations

6.1.  Verification Mandate

   The verification mandate of [MCPDNS] Section 12.3 is the security
   floor of this scheme.  Handlers that accept an alter: URI without
   verifying the envelope's signature against the DNSSEC-validated
   publishing record violate the scheme's invariants.  An attacker who
   induces a handler to perform unverified retrieval can substitute an
   envelope.  Implementations MUST treat envelope verification as a
   precondition to any side effect (writing files, sending requests,
   dispatching a sub-handler, or performing an addressed action).

6.2.  Action-Address Confusion

   Because an alter: URI MAY address a typed action, a handler that acts
   on the action-path before verifying the envelope exposes a confused-
   deputy surface: an attacker-supplied URI could name a privileged
   action under a handle the attacker does not control.  The Step-4
   verification MUST complete, binding the resolved envelope to the
   addressed handle, before any action-path is dispatched.  A handler
   MUST NOT infer authority from the URI's textual form alone.

Morrison                  Expires 24 April 2027                [Page 14]
Internet-Draft              alter URI Scheme                October 2026

6.3.  Context Reference Confusion

   A context artefact reference (Section 3.8) is a claim to verify,
   never authority to assume.  A handler that treats the mere presence
   of a context artefact reference in an inbound request as sufficient
   to act under that context, without a separate admission step re-
   deriving the verdict against the principal's actual holdings,
   reproduces the confused-deputy surface described in Action-Address
   Confusion above, for the context axis rather than the action axis.

   A context artefact is a private holding, blind to every other context
   the same principal holds.  The resolution procedure for a context
   artefact reference MUST NOT expose, to any party other than the
   presenting principal's own bound credential, the existence, name, or
   count of any other context the same principal holds.  An unresolvable
   context-ref and a context-ref the resolver declines to answer MUST be
   indistinguishable; a resolver that distinguishes them creates an
   existence oracle over the principal's context set.

   This document specifies no resolution path for a context artefact
   reference other than resolution by its holder, using the holder's own
   bound credential.  It neither describes nor forbids resolution by any
   other party.

6.4.  Handler Substitution

   The operating-system's default-application policy is the trust-anchor
   for which binary handles alter: URIs.  Users configuring the default
   handler MUST treat handler selection with the same caution they apply
   to default browsers or default mail clients.  A malicious handler
   could parse an alter: URI, present a forged envelope to the user, and
   act on attacker-supplied data without performing verification.  This
   document defines no manifest against which a handler binary could be
   checked.

6.5.  Path-Component Privacy

   An organisational scope, facet, or action-path included in an alter:
   URI is part of the URI's textual form and may be logged by the
   operating-system handler registry, browser history, terminal
   scrollback, and chat-client indexers.  Surface owners that consider a
   facet or action identifier (e.g. a decision identifier, a thread
   identifier) sensitive SHOULD provide indirected forms (opaque tokens,
   ephemeral identifiers) and SHOULD NOT recommend embedding sensitive
   identifiers in the URI.

Morrison                  Expires 24 April 2027                [Page 15]
Internet-Draft              alter URI Scheme                October 2026

6.6.  Ref-Segment Traversal

   An artefact-ref is a sequence of named segments, not a filesystem
   path.  A ref-segment MUST NOT be . or .., and MUST NOT be empty.  An
   artefact-ref of ../secret, one of /etc/passwd (whose first segment is
   empty), and an artefact-ref-form URI ending in / are therefore all
   malformed and MUST be rejected.  Implementations MUST reject them on
   the textual form, before any resolution is attempted, and MUST NOT
   normalise a navigation segment away and resolve what remains: a
   resolver that receives an already-normalised reference cannot tell
   that a traversal was ever requested.  The percent-encoded spellings
   of these segments are covered by the same rule, because pct-encoded
   decoding happens before a segment is compared.

6.7.  Cross-Scheme Confusion

   A URI in which the scheme separator alter: is followed by //, the
   introducer of an [RFC3986] authority component, is malformed and MUST
   be rejected.  Implementations MUST NOT silently coerce such a URI to
   the same URI without the double slash; divergent parsers risk
   confusing a third-party authority component with a handle reference.
   Similarly, the @ of an org-scope MUST NOT be parsed as an [RFC3986]
   userinfo delimiter; there is no authority component in an alter: URI.

6.8.  Form Confusion

   The two forms defined in Section 3.3 share one scheme prefix and are
   discriminated solely by the octet following the scheme separator.  A
   parser that accepts a leading tilde character inside an artefact-type
   production, or that treats an artefact-ref-form URI as containing a
   handle-ref when no tilde is present, breaks the partition between the
   two forms and creates a parser-divergence surface: two conforming
   implementations could disagree about which form a given URI carries,
   and an attacker could craft a URI that one implementation resolves as
   a handle reference and another resolves as an artefact reference.
   Implementations MUST reject any URI in which the octet following
   alter: is neither U+007E TILDE nor a lowercase ALPHA.
   Implementations MUST NOT attempt handle-ref-form parsing on a URI
   beginning with a lowercase ALPHA, and MUST NOT attempt artefact-ref-
   form parsing on a URI beginning with U+007E.  A handler that
   dispatches based on a partial or best-effort match of either form,
   rather than a full match against the discriminator rule of
   Section 3.3, is non-conforming.

Morrison                  Expires 24 April 2027                [Page 16]
Internet-Draft              alter URI Scheme                October 2026

6.9.  Handle-Domain Confusion

   handle-name admits U+002E FULL STOP, because the tier productions it
   mirrors from [MCPDNS] use a trailing .bot label to carry the bot tier
   lexically.  A handle-name may therefore be spelled so that it
   resembles a DNS domain name.  alter:~example.com is a well-formed
   handle reference naming a principal whose handle is example.com; it
   is not a reference to the example.com zone, and nothing in this
   scheme gives it one.

   Implementations MUST NOT derive DNS meaning from the lexical form of
   a handle-name, MUST NOT resolve a handle through DNS on the basis of
   its spelling, and MUST NOT treat a handle ending in a public suffix
   as evidence of any relationship to the corresponding domain.  An
   association between a domain and a handle is established out of band
   and is never inferred from the handle's characters.  A surface that
   renders a handle to a person MUST retain the leading tilde, because a
   handle stripped of its tilde and placed where a reader expects a
   domain cannot be distinguished from one.  Only a trailing .bot label
   carries meaning under [IDCOMMITS]; no other label within a handle-
   name carries any.

6.10.  IRI Considerations

   When an alter: URI is presented in IRI form per [RFC3987] with non-
   ASCII characters in the action-path, implementations MUST apply the
   conversion procedure of [RFC3987] Section 3.1 before performing the
   resolution procedure.  Non-ASCII characters in the handle-ref, org-
   scope, or facet MUST be rejected; those productions are restricted to
   the ASCII forms above.

7.  IANA Considerations

   Provisional registration of the alter URI scheme in the Uniform
   Resource Identifier (URI) Schemes registry was requested of IANA on
   30 September 2026, under [RFC7595] Section 4 and the procedure of
   [RFC7595] Section 7.2, and IANA registered the scheme as Provisional
   on 5 October 2026, citing revision 03 of this document.  [MCPDNS]
   Section 11 and [MCPDNS] Section 16.2 cross-reference the
   registration.  The template submitted is:

   *  URI scheme name: alter

   *  Status: Provisional

   *  URI scheme syntax: As specified in Section 3.3 above.

   *  URI scheme semantics: As specified in Section 3.4 above.

Morrison                  Expires 24 April 2027                [Page 17]
Internet-Draft              alter URI Scheme                October 2026

   *  Encoding considerations: As specified in Section 3.5 above.

   *  Applications/protocols that use this URI scheme name: As specified
      in Section 3.6 above.

   *  Interoperability considerations: As specified in Section 3.7
      above.

   *  Security considerations: As specified in Section 6 above.

   *  Contact: Blake Morrison blake@truealter.com
      (mailto:blake@truealter.com), Alter Meridian Pty Ltd.

   *  Author/Change controller: Blake Morrison, Alter Meridian Pty Ltd.
      Change control transfers to the IETF if this scheme is later
      specified by an IETF Stream document.

   *  References: This document; [MCPDNS]; [IDCOMMITS].

   Permanent registration, against the requirements of [RFC7595]
   Section 3, is the intended upgrade path once the scheme specification
   stabilises.

8.  Acknowledgements

   The scheme builds on the ~handle identity primitive defined in
   [MCPDNS] and the tier taxonomy of [IDCOMMITS].  The lexical choice of
   tilde for the handle prefix is informed by [POSIX-TILDE] and by the
   long-standing shell convention that the tilde denotes a named
   principal.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

Morrison                  Expires 24 April 2027                [Page 18]
Internet-Draft              alter URI Scheme                October 2026

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/info/rfc7595>.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <https://www.rfc-editor.org/info/rfc3987>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
              via DNS TXT Records", Work in Progress, Internet-Draft,
              draft-morrison-mcp-dns-discovery-09, 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
              discovery/>.

   [IDCOMMITS]
              Morrison, B., "Identity-Attributed Git Commits via Tier-
              Structured Trailers", Work in Progress, Internet-Draft,
              draft-morrison-identity-attributed-commits-04, 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              attributed-commits/>.

10.  Informative References

   [IDACCORD] Morrison, B., "Identity Accord Protocol", Work in
              Progress, Internet-Draft, draft-morrison-identity-accord-
              03, 2026, <https://datatracker.ietf.org/doc/draft-
              morrison-identity-accord/>.

   [IDPRONOUNS]
              Morrison, B., "Identity Pronouns: A Reference-Axis
              Extension to ~handle Identity Systems", Work in Progress,
              Internet-Draft, draft-morrison-identity-pronouns-05, 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              pronouns/>.

Morrison                  Expires 24 April 2027                [Page 19]
Internet-Draft              alter URI Scheme                October 2026

   [POSIX-TILDE]
              "IEEE Std 1003.1-2017, Shell Command Language,
              Section 2.6.1 Tilde Expansion", 2017,
              <https://pubs.opengroup.org/onlinepubs/9699919799/>.

   [XDG-MIME] "Shared MIME-info Database Specification", 2024,
              <https://specifications.freedesktop.org/shared-mime-info-
              spec/latest/>.

   [LSHANDLERS]
              "CFBundleURLTypes (Information Property List)", 2024,
              <https://developer.apple.com/documentation/
              bundleresources/information-property-list/
              cfbundleurltypes>.

Appendix A.  Change Log

A.1.  draft-morrison-alter-uri-scheme-05

   *  Rewrite the prose against the drafting rules and pin each citation
      of another Internet-Draft to its latest posted revision.  The
      grammar, the examples and every requirement are unchanged.

A.2.  draft-morrison-alter-uri-scheme-04

   *  Correct the section references into [MCPDNS]: the envelope record
      is [MCPDNS] Section 7, and the resolution and verification
      procedure is [MCPDNS] Section 12.3.  Revision 03 cited Sections 5
      and 8 of that document for them.

   *  State that a handle carries no zone of its own.  Step 2 of
      Section 3.4 takes the zone from org-scope, or from an association
      held out of band, and otherwise treats the reference as
      unresolvable; it no longer points at a handle-to-zone procedure in
      [MCPDNS], because that document defines none.  Note this in the
      org-scope definition and under the Addressing Examples.

   *  Remove the statement that [MCPDNS] falls back to an HTTPS well-
      known surface for envelope retrieval.  [MCPDNS] defines no such
      fallback, and the statement contradicted Section 3.7.  Drop the
      [RFC8615] reference, since nothing else cited it.

Morrison                  Expires 24 April 2027                [Page 20]
Internet-Draft              alter URI Scheme                October 2026

   *  State that an Instrument-tier handle is not an independent handle
      and has no envelope of its own, matching [MCPDNS] Section 2, and
      that a handler MUST NOT treat one as naming an independent
      principal.  Correct the Introduction to match, remove the
      Instrument-tier addressing example, and attribute the cc- prefix
      in the ABNF comments to [MCPDNS] rather than [IDCOMMITS].  The
      grammar is unchanged.

   *  Correct the [RFC7595] section references: provisional registration
      is [RFC7595] Section 4, the registration procedure is [RFC7595]
      Section 7.2, and the requirements for permanent registration are
      [RFC7595] Section 3.

   *  Record in the Abstract, Status and IANA Considerations that
      provisional registration was requested on 30 September 2026 and
      that IANA registered the scheme as Provisional on 5 October 2026.

   *  Correct the iOS registration text: a custom scheme is registered
      with CFBundleURLTypes in Info.plist, as on macOS; associated
      domains and universal links serve https: URLs.

   *  Describe the one command-line client that accepts alter: URIs as
      it is: it does not register as an operating-system handler and
      does not run the resolution procedure.  Remove the statement that
      it registers itself as the default handler.

   *  Reduce the Artefact Type Genus Membership subsection to the rule
      for admitting a member, and remove the list of members that named
      one implementation's own artefact kinds and file titles.  Replace
      the examples that used them in Terminology and under Ref-Segment
      Traversal with generic ones.

   *  Replace the closing paragraph of Context Reference Confusion: this
      document specifies no resolution path for a context artefact
      reference other than its holder's, and neither describes nor
      forbids resolution by another party.

   *  Remove a SHOULD that depended on a handler manifest no
      specification defines.

   *  Replace the hand-typed BCP 14 paragraph with the standard
      boilerplate, use a neutral handle in the examples, remove a
      statement of the document's own contribution from the Abstract,
      and name in words the documents the Abstract relies on, where it
      had cited them by tag.

Morrison                  Expires 24 April 2027                [Page 21]
Internet-Draft              alter URI Scheme                October 2026

   *  Describe the malformed forms under Ref-Segment Traversal and
      Cross-Scheme Confusion without spelling each as a complete URI.
      The requirements are unchanged.

   *  Shorten the Abstract, Introduction, Status and Scheme Semantics
      prose.  No requirement changes.

   *  Correct step 5 of Scheme Semantics, where a facet or action-path
      was dispatched to a resolver named by the envelope.  The envelope
      names none; the step now defers to the specification that defines
      the facet or action surface.

A.3.  draft-morrison-alter-uri-scheme-03

   *  Add a Handle-Domain Confusion security consideration.  Because
      handle-name admits "." in order to carry the .bot tier suffix of
      [IDCOMMITS], a handle may be spelled to resemble a DNS domain.
      State that no DNS meaning follows from a handle's lexical form,
      that a domain's association with a handle is established out of
      band, and that a rendering surface MUST retain the leading tilde.

   *  Partition the scheme into two disjoint reference forms carried
      under one scheme name: handle-ref-form, unchanged from revision
      02, and a new artefact-ref-form, alter:<artefact-type>/<artefact-
      ref>, addressing a typed artefact rather than a ~handle.

   *  Add a discriminator rule: the octet immediately following the
      scheme separator selects the form, U+007E TILDE for a handle
      reference and a lowercase ALPHA for an artefact reference.  No
      other leading octet is valid, and the tilde MUST NOT begin an
      artefact type.

   *  Add Artefact type and Artefact reference to Terminology, defining
      the shape of the reference only, and state that this document
      assigns artefact resolution no meaning.

   *  Make artefact-ref a sequence of ref-segments separated by "/", so
      that a scoping name can precede the reference it scopes, and widen
      each segment to 1*( unreserved / pct-encoded ) so that a ~handle
      or its percent-encoded form can be carried.  Make the artefact-ref
      component OPTIONAL so that a bare artefact type is expressible.

   *  Add Form Confusion and Ref-Segment Traversal security
      considerations.  A ref-segment MUST NOT be "." or "..", and is
      rejected on its textual form, after pct-encoded decoding, before
      any resolution.

Morrison                  Expires 24 April 2027                [Page 22]
Internet-Draft              alter URI Scheme                October 2026

   *  Add context as a member of the artefact-type genus, with a Context
      Artefact Type subsection specifying context-ref-form and the
      RESERVED personal literal, and a Context Reference Confusion
      security consideration.  Define org-scope as a DNS zone qualifier
      that carries no acting context.

   *  Add an Artefact Type Genus Membership subsection listing further
      members of the genus.

   *  Repoint the informative Apple reference to the current
      CFBundleURLTypes page.  The mechanism cited is unchanged.

A.4.  draft-morrison-alter-uri-scheme-02

   *  Broaden the addressing syntax to the full ~handle@org:facet/action
      reference: add the org-scope, facet, and action-path productions
      and their left-to-right parsing rules.  Every added component is
      OPTIONAL; a bare alter:~handle is unchanged.

   *  State explicitly that facet and action-path are addressing
      information only, with resolution semantics owned by the surface
      specification and out of scope here.

   *  Add an Action-Address Confusion security consideration and extend
      the verification mandate to cover addressed actions.

   *  Correct the registration Status to Provisional, matching the
      registration this document actually requests; record permanent
      registration as the intended upgrade path rather than asserting
      it.

A.5.  draft-morrison-alter-uri-scheme-01

   *  Editorial and reference alignment.

A.6.  draft-morrison-alter-uri-scheme-00

   *  Initial submission.  Upgrades the provisional registration
      recorded in [MCPDNS] Section 11.

Author's Address

   Blake Morrison
   Alter Meridian Pty Ltd
   Email: blake@truealter.com

Morrison                  Expires 24 April 2027                [Page 23]