| Internet-Draft | alter URI Scheme | May 2026 |
| Morrison | Expires 16 November 2026 | [Page] |
This document defines the alter URI scheme as a dispatchable
reference syntax for ~handle identity references published under
the DNS substrate defined in [MCPDNS]. An alter: URI binds a
textual ~handle reference, with an optional surface path, to a
resolution and verification procedure that retrieves the handle's
envelope from the publishing zone, validates the envelope's
signature chain, and dispatches the result to an operating-system
URI handler. The scheme is provisionally registered under [MCPDNS]
Section 11; this document is the full registration request per
[RFC7595] Section 3.¶
The scheme is provider-neutral, introduces no new cryptographic
primitive, and reuses the resolution and verification procedures
of [MCPDNS] without modification. The principal contribution is
to give operating systems, browsers, chat clients, and command-line
tools a single dispatch surface for handle-typed references so that
clicking, typing, or scanning an alter: URI yields a verified
handle resolution rather than a free-text string.¶
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 16 November 2026.¶
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.¶
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."¶
The ~handle identity primitive defined in [MCPDNS] binds a textual
identifier (Sovereign, Bot, or Instrument tier per [IDCOMMITS]) to
a cryptographic principal published under an _alter. DNS TXT
record. A handle reference written in running text -- ~blake,
~truealter.com, ~cc-opus-4-7 -- 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,
with an optional surface path, to the resolution procedure of
[MCPDNS] and to a URI handler registered with the host operating
system. Once a handler is installed, clicking alter:~blake in a
browser, chat window, or terminal yields a verified envelope; the
handler decides what to do with the resulting envelope (open an
inbox, show a profile card, initiate an Accord ceremony per
[IDACCORD], dispatch to a per-surface MCP tool).¶
The scheme is provisionally registered in [MCPDNS] Section 11. This document is the standalone registration request submitted to IANA per [RFC7595] Section 3, separating the administrative ceremony of scheme registration from the substantive specification of the DNS substrate.¶
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.¶
~handleA textual identity reference defined in [MCPDNS] and tiered in [IDCOMMITS]. Handles begin with the tilde character U+007E.¶
The signed identity record retrieved from the _alter.<domain>
DNS TXT record of the publishing zone, as specified in [MCPDNS]
Section 5.¶
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, registry entries under HKCR on Windows,
intent filters on Android, and universal links on iOS.¶
A named addressable resource under a handle, expressed as the
path component of the URI (e.g. decisions/123, inbox,
seat/architect).¶
alter¶
Permanent. The registration upgrades the provisional registration recorded under [MCPDNS] Section 11.¶
The alter URI scheme's generic syntax conforms to [RFC3986]:¶
alter-URI = "alter:" handle-ref [ "/" handle-path ] [ "?" query ]
[ "#" fragment ]
handle-ref = "~" handle-name
handle-name = sovereign-name / bot-name / instrument-name
sovereign-name
= ALPHA *( ALPHA / DIGIT / "-" / "." )
; Per [IDCOMMITS] Section 4.
bot-name = ALPHA *( ALPHA / DIGIT / "-" / "." ) ".bot"
instrument-name
= "cc-" 1*( ALPHA / DIGIT / "-" / "." )
; Per [IDCOMMITS] Section 4.
handle-path = segment *( "/" segment )
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 = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
¶
The handle-name ABNF mirrors the tier productions of [IDCOMMITS]
without restating tier-level invariants; an alter: URI carries a
single handle and the parser determines the tier from the lexical
form.¶
The host-component slot of a generic URI is not used. All
identity-bearing material is carried in the path-like handle-ref
production immediately after the scheme separator.¶
Operations on an alter: URI are retrieval-by-default. Submitting
an alter: URI to a handler MUST perform the resolution and
verification procedure specified in [MCPDNS] Section 8 before any
content or directive derived from the resulting envelope is acted
upon. Specifically, the handler MUST:¶
Parse the URI per the ABNF above.¶
Resolve ~handle to a publishing zone via the procedures of
[MCPDNS] Section 6.¶
Retrieve and DNSSEC-validate [RFC4033] the _alter.<zone> TXT
record.¶
Verify the envelope signature against the published Ed25519 key per [MCPDNS] Section 8.¶
If a handle-path is present, dispatch the surface request to
the resolver indicated by the envelope. Surface dispatch
semantics are scheme-neutral and out of scope for this document.¶
Handlers SHOULD treat any verification failure as a hard error and SHOULD NOT fall back to unverified retrieval.¶
alter URIs are ASCII per [RFC3986]; characters outside the
unreserved set MUST be percent-encoded. The IRI form per [RFC3987]
is supported for handle-paths that contain non-ASCII characters;
the handle-ref itself MUST be ASCII to align with the DNS label
production of [MCPDNS]. The tilde character U+007E is reserved as
the handle prefix and is treated as a literal, not as an
unreserved-character escape.¶
The reference substrate operating at ~truealter.com uses alter:
URIs to dispatch handle references between operating-system
handlers, the alter command-line interface, chat clients, and
agent runtimes that consume the DNS substrate of [MCPDNS]. Any
agent runtime, client, or operating-system component that resolves
~handle references can register a handler for the scheme.¶
Operating-system URI handler registries are well-defined for each target platform:¶
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: associated-domains and universal-link entitlement entries.¶
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] does not run over HTTP.¶
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.¶
See Section 5 below.¶
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.¶
A .desktop file with MimeType=x-scheme-handler/alter; and a
Exec= line invoking the platform resolver. The alter-cli
reference implementation registers itself as the default handler
on first run.¶
A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") and
a CFBundleURLName of Identity Handle Reference in the
application's Info.plist.¶
The following non-normative examples illustrate the path syntax. Surface semantics are out of scope; each surface is defined by the specification that owns it.¶
alter:~blake alter:~truealter.com/decisions/123 alter:~drew/inbox alter:~truealter.com/seat/architect alter:~cc-opus-4-7/sessions/last¶
The first form addresses an envelope; the second through fourth forms address surfaces under an envelope; the fifth form illustrates Instrument-tier surfaces.¶
The verification mandate of [MCPDNS] Section 8 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).¶
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. Implementations SHOULD
cross-check the handler binary's signature against the publishing
substrate's expected handler manifest where such a manifest is
defined by a future specification.¶
A handle-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 path 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's
path component.¶
A URI of the form alter://~blake (with the authority-component
double-slash) is malformed and MUST be rejected. Implementations
MUST NOT silently coerce alter://~handle to alter:~handle;
divergent parsers risk confusing a third-party authority component
with a handle reference.¶
When an alter: URI is presented in IRI form per [RFC3987] with
non-ASCII characters in the handle-path, implementations MUST
apply the conversion procedure of [RFC3987] Section 3.1 before
performing the resolution procedure. Non-ASCII characters in the
handle-ref itself MUST be rejected; handle names are restricted
to the ASCII production above.¶
This document requests that IANA register the alter URI scheme
in the Uniform Resource Identifier (URI) Schemes registry per
[RFC7595] Section 7, replacing the provisional registration
recorded under [MCPDNS] Section 11 with the following permanent
registration:¶
URI scheme name: alter¶
Status: Permanent¶
URI scheme syntax: As specified in Section 3.3 above.¶
URI scheme semantics: As specified in Section 3.4 above.¶
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 5 above.¶
Contact: Blake Morrison blake@truealter.com, Alter Meridian Pty Ltd, Cronulla, NSW, Australia.¶
Author/Change controller: IETF.¶
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.¶