]> Alter Meridian Pty Ltd

Cronulla, NSW Australia blake@truealter.com

This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published under the DNS substrate defined in . 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 Section 11; this document is the full registration request per Section 3. The scheme is provider-neutral, introduces no new cryptographic primitive, and reuses the resolution and verification procedures of 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.

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."

Introduction The ~handle identity primitive defined in binds a textual identifier (Sovereign, Bot, or Instrument tier per ) 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 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 , dispatch to a per-surface MCP tool). The scheme is provisionally registered in Section 11. This document is the standalone registration request submitted to IANA per Section 3, separating the administrative ceremony of scheme registration from the substantive specification of the DNS substrate.

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 when, and only when, they appear in all capitals, as shown here.

Terminology

~handle

A textual identity reference defined in and tiered in . 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 Section 5.

Handler

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

Surface

A named addressable resource under a handle, expressed as the path component of the URI (e.g. decisions/123, inbox, seat/architect).

Scheme Definition

Scheme Name alter

Status Permanent. The registration upgrades the provisional registration recorded under Section 11.

URI Scheme Syntax The alter URI scheme's generic syntax conforms to : The handle-name ABNF mirrors the tier productions of 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.

Scheme Semantics 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 Section 8 before any content or directive derived from the resulting envelope is acted upon. Specifically, the handler MUST:

1. Parse the URI per the ABNF above.
2. Resolve ~handle to a publishing zone via the procedures of Section 6.
3. Retrieve and DNSSEC-validate the _alter.<zone> TXT record.
4. Verify the envelope signature against the published Ed25519 key per Section 8.
5. 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.

Encoding Considerations alter URIs are ASCII per ; characters outside the unreserved set MUST be percent-encoded. The IRI form per 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 . The tilde character U+007E is reserved as the handle prefix and is treated as a literal, not as an unreserved-character escape.

Applications and Protocols That Use This Scheme 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 . Any agent runtime, client, or operating-system component that resolves ~handle references can register a handler for the scheme.

Interoperability Considerations Operating-system URI handler registries are well-defined for each target platform:

• Linux desktops: xdg-mime associations .
• macOS: CFBundleURLSchemes entries in an application's Info.plist .
• 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 does not run over HTTP. The alter scheme does not displace any existing scheme and does not contradict the path-handling rules of . It coexists with https:, mailto:, and other schemes that an operating system may dispatch on the same surface.

Security Considerations See Section 5 below.

Author / Change Controller IETF, with change requests routed via the document author: Blake Morrison, Alter Meridian Pty Ltd, blake@truealter.com.

References , , , .

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.

Linux desktops 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.

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

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.

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

iOS An associated-domains entitlement listing the publishing zone, plus a LSApplicationQueriesSchemes entry that includes alter.

Surface-Path Examples 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. The first form addresses an envelope; the second through fourth forms address surfaces under an envelope; the fifth form illustrates Instrument-tier surfaces.

Security Considerations

Verification Mandate The verification mandate of 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).

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. 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.

Path-Component Privacy 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.

Cross-Scheme Confusion 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.

IRI Considerations When an alter: URI is presented in IRI form per with non-ASCII characters in the handle-path, implementations MUST apply the conversion procedure of 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.

IANA Considerations This document requests that IANA register the alter URI scheme in the Uniform Resource Identifier (URI) Schemes registry per Section 7, replacing the provisional registration recorded under 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.
• References: This document; ; .

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Alter Meridian Pty Ltd Alter Meridian Pty Ltd Informative References This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Alter Meridian Pty Ltd Alter Meridian Pty Ltd

Change Log

draft-morrison-alter-uri-scheme-00

• Initial submission. Upgrades the provisional registration recorded in Section 11.