]> Alter Meridian Pty Ltd

blake@truealter.com

This document specifies the did:alter Decentralized Identifier method. A did:alter identifier names a ~handle together with the DNS zone that publishes the handle's signed envelope, and it resolves to a DID document by running the envelope recognition procedure of the companion specification for discovering Model Context Protocol servers through DNS TXT records, then expressing the verified envelope's Ed25519 key as a verification method. The identifier agrees with the handle grammar of the alter URI scheme and with the did:alter form already written by the identity-attributed commits specification. The method introduces no new record, no new cryptographic primitive and no registry of its own: create, update and deactivate are the publication, replacement and revocation of that envelope, and read is its verification. The document also sets out what the method cannot yet do, because the envelope record it reads carries no key history, and revocation cannot presently be observed from DNS alone.

Introduction A ~handle is a textual identity reference with a tier read from its lexical form . Its key is published in a signed envelope at _alter.<zone>, and a resolver recognises the handle by retrieving that record, validating it under DNSSEC and checking the envelope signature . The alter: URI is the dispatchable form of the same reference for operating-system handlers. Software built on Decentralized Identifiers cannot use either form directly. A verifier of Verifiable Credentials, a wallet, or any component that expects a DID needs a DID method that says how the identifier is spelled, how it is resolved to a DID document, and what the security and privacy properties of that resolution are. This document is that method for handles. The method is a thin mapping. It defines:

• the did:alter method-specific identifier, in ABNF, built from the handle grammar of and the organisational scope that names the publishing zone (Section 3);
• the DID document a resolver produces from a verified envelope (Section 4);
• the create, read, update and deactivate operations, each in terms of the envelope record and procedure of (Section 5);
• the security and privacy considerations those operations inherit, and the ones they add (Sections 7 and 8).

It does not define a new record, a new key type, a service type, a caveat surface or a fallback resolution path. Where leaves something unspecified, such as where a revocation is published, this document leaves it unspecified too and says what a resolver can and cannot conclude. The examples use the handles ~alice, ~carol and ~acme, and zones under the example name reserved for documentation.

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

DID, DID document, DID URL, DID resolver, verification method,

DID resolution metadata and DID document metadata

As defined in .

~handle

A textual identity reference beginning with U+007E TILDE, with its tier (Sovereign, Bot or Instrument) determined by its lexical form, as defined by the handle-name production of .

Zone

The DNS zone under which a handle's envelope is published at the owner name _alter.<zone>. In an alter: URI the zone is the org-scope component .

Envelope

The signed identity record retrieved from _alter.<zone>, with the seven required fields v, h, pk, ilr, ts, rev and sig .

Recognition

The procedure of that retrieves, DNSSEC-validates and signature-verifies an envelope for a given zone and handle. An envelope that procedure treats as verified is a verified envelope.

did:alter DID

A DID whose method name is alter and whose method-specific identifier conforms to Section 3.

Method-Specific Identifier

Method Name The method name is alter. A DID that uses this method begins with the string did:alter:, in lowercase, as requires.

Syntax The method-specific identifier carries a handle and, optionally, the zone that publishes it. The following ABNF defines it. handle-name and org-scope are the productions of the same names in Section 3.3 of , imported without change. The percent-encoded spelling , %7E for "~" and %40 for "@", is the canonical form of a did:alter DID. It is the only spelling that meets the idchar production of , as that production admits neither "~" nor "@". Every DID a resolver or publisher emits, and every id, controller and verification method identifier in a DID document, MUST use the canonical form. The literal spelling is the display form. It is the form written by and by the alter: URI, and an application SHOULD show a did:alter DID to a person in its display form. A resolver MUST accept either spelling on input and MUST convert it to the canonical form as Section 3.4 states before any other step. The handle and zone are ASCII. A non-ASCII character in either MUST cause the resolver to return the invalidDid error of . This document defines no path and no query for a did:alter DID URL. A DID URL carrying either is not defined by this document, and a resolver MUST NOT dereference it as though the path or query were absent.

Examples The first three name a Sovereign-tier handle published under its own zone. The fourth is a DID URL naming the verification method of Section 4. The fifth carries no zone, which is the form of , and resolves only as Section 5.2 allows. Their display forms are did:alter:~alice@alice.example, did:alter:~acme@acme.example, did:alter:~carol@carol.acme.example, did:alter:~alice@alice.example#key-1767225600 and did:alter:~alice. The corresponding alter: URI is the display form with the did: prefix dropped, for example alter:~alice@alice.example.

Normalisation and Equivalence Before comparing two did:alter DIDs, or using one as a cache key, a resolver MUST normalise each to the canonical form, by encoding "~" as %7E and "@" as %40, writing every percent-encoded hexadecimal digit in uppercase, and converting the zone to lowercase. Two DIDs are equivalent when their normalised forms are identical octet for octet. The handle is compared exactly, without case folding. Neither nor states whether handle comparison is case-sensitive, and the h= match of the recognition procedure is a string match; this document therefore takes the stricter reading. Publishers SHOULD use lowercase handles.

The Zone Is Never Derived from the Handle A handle can be spelled so that it resembles a domain name, as ~example.com does. The handle-domain confusion consideration of Section 6.9 of applies to every did:alter DID: a resolver MUST NOT take the zone from the spelling of handle-name, and MUST NOT resolve did:alter:~example.com against the zone example.com unless that zone is the one the DID names after at or the association is held as Section 5.2 allows.

The DID Document A resolver that has a verified envelope for the requested handle produces a DID document in the JSON representation of , with the media type application/did+json. The document is a total function of the verified envelope and the requested DID: two resolvers that verify the same envelope produce the same document. The members are these, and no others.

id

The requested DID in its canonical form (Section 3.4), without any fragment.

controller

The value of id. The handle controls its own DID; Section 7.1 says what that control rests on.

alsoKnownAs

A one-element array holding the alter: URI of the same handle and zone, as in Section 3.3. Where the DID carries no zone, the member is omitted.

verificationMethod

A one-element array holding the envelope key, expressed as a verification method of type JsonWebKey :

• id is the value of the document's id followed by #key- and the decimal digits of the envelope's ts field, verbatim;
• type is JsonWebKey;
• controller is the value of the document's id;
• publicKeyJwk is a JSON Web Key of the Octet Key Pair type defined by , whose kty is OKP, whose crv is Ed25519, and whose x is the base64url value that follows ed25519: in the envelope's pk field, copied without re-encoding. No conversion is performed, because both encodings are base64url without padding over the 32 key octets.

authentication and assertionMethod

Each a one-element array holding the id of that verification method.

The fragment carries the envelope's inception timestamp because a signature naming the key of an earlier envelope has to be visibly different from one naming the current key, and a fixed label would make the two identical. Section 6 says why a resolver cannot yet produce the earlier key itself. The following is the document for did:alter:%7Ealice%40alice.example where the verified envelope carries ts=1767225600 and the public key of the Ed25519 test vector in Appendix A of . The document is JSON . This document defines no service type and adds no service member. A specification that defines a service reachable through a handle MAY define how a resolver adds one. The resolver also returns DID document metadata, with created set to the envelope's ts expressed as an XML Schema dateTime in UTC, and with deactivated set to true only as Section 5.4 provides.

Operations

Create A did:alter DID comes into being when its envelope is published. There is no registration step and no registry. To create one, the controller of a zone:

1. generates an Ed25519 key pair and a secret revocation pre-image;
2. builds an envelope binding the handle to the public key, with rev set to the SHA-256 digest of the pre-image and ts set to the inception time, and signs it, all as specifies;
3. publishes the envelope as the TXT record at _alter.<zone> in a DNSSEC-signed zone, holding the envelope of that one handle only, as requires.

The DID is then did:alter: followed by the handle and, after at, the zone. Since an Instrument-tier handle has no envelope of its own , no did:alter DID is created for one. Section 7.1.1 of states that publishing a per-individual envelope in DNS is NOT RECOMMENDED, for reasons of enumeration, size and erasure. Those reasons apply to every did:alter DID that names a natural person, and Section 8 restates them.

Read (Resolve) Given a did:alter DID, a resolver MUST perform these steps in order.

1. Parse. Parse the DID against Section 3.2. On failure, return invalidDid. Normalise it per Section 3.4.
2. Tier. If handle-name is Instrument-tier, return notFound. An Instrument-tier handle names no independent principal , and a resolver MUST NOT return a DID document for one.
3. Zone. Take the zone from the DID. Where the DID carries no zone, the resolver proceeds only if it holds an association between the handle and a zone established out of band, as Section 3.4 of allows for a URI with no org-scope; otherwise it returns notFound. The zone is never derived from the handle (Section 3.5).
4. Recognise. Run the envelope recognition procedure of with that zone and the handle. Every step that procedure makes fatal is fatal here. If the envelope is not verified, return notFound and no document. A resolver MUST NOT return a document built from an unverified envelope, and MUST NOT fall back to unvalidated DNS or to any other source.
5. Revocation. Where the resolver has access to a revocation surface and observes that the pre-image of rev has been revealed, it proceeds to Section 5.4. Being unable to perform this check does not stop resolution, as provides, and the resolver MUST NOT report the DID as not deactivated on the strength of a check it did not perform.
6. Build. Build the DID document of Section 4 from the verified envelope.
7. Return. Return the document, its metadata, and DID resolution metadata whose contentType is application/did+json.

A resolver MAY cache a result for no longer than allows for a cached verification of the envelope, and MUST re-run any revocation check it is able to perform on each resolution rather than on each cache refresh.

Update The controller updates a did:alter DID by replacing the envelope at _alter.<zone> with a new envelope for the same handle, carrying the new key, a new ts, a new rev commitment and a new signature. The DID itself does not change. The verification method's fragment does, because it carries ts. A resolver that has resolved the DID before MAY retain the key it last returned. Where a later resolution yields a different key, the resolver SHOULD surface the change to whatever relies on it, and MUST NOT treat the new key as continuous with the old on the strength of the record alone, for the reason given in Section 7.2.

Deactivate A did:alter DID is deactivated by revocation of its envelope: revealing the pre-image whose SHA-256 digest is the envelope's rev value, as specifies. From that moment every claim signed under the envelope's key is invalid, whenever it was signed. A resolver that observes such a reveal MUST return DID document metadata with deactivated set to true, and MUST NOT return the verification method as usable for authentication or assertion. Removing the TXT record is not deactivation. holds that absence of the record is indistinguishable from misconfiguration and is never revocation. A resolver that finds no record returns notFound, never deactivated. does not specify where a reveal is published, and states that revocation status cannot presently be established from DNS alone. A resolver working from this document and therefore cannot observe deactivation, and Section 7.3 sets out the consequence.

Key History names the key that signed a commit by a did:alter DID URL with a fragment, and says a sovereign's DNS record may publish several historical keys indexed by that fragment. The envelope of carries one key and no key identifier, and a zone publishes one envelope per owner name. No resolver can therefore retrieve an earlier key from DNS. This document does not add a key-history field. A resolver resolves only the current envelope. A verifier presented with a DID URL whose fragment names a ts other than the current envelope's knows that the signature was made under an earlier envelope, and MUST treat the signature as unverified unless it holds that earlier key from a verification it performed itself while that envelope was current.

Security Considerations The security considerations of and of apply in full. The following are specific to using the envelope as a DID.

Control Rests on the Zone The envelope signature is checked against the key in the same envelope. It proves the record is internally consistent; it does not prove that the party who published it is the party who published the previous one. Control of a did:alter DID is therefore control of the DNS zone it names, as it is for the web DID method . An attacker who gains control of the zone, through registrar compromise, an expired registration or a compromised signing key for the zone, can publish a new envelope and will be resolved as the DID's controller. Section 5.2 makes DNSSEC validation fatal, and that defends against an attacker on the path but not against one who controls the zone.

Key Change Without Continuity The envelope record has no key-continuity rule of its own. A resolver cannot distinguish a rotation by the rightful controller from a replacement by someone who has taken the zone. Section 5.3 therefore asks that a change of key be surfaced and not accepted silently. A relying party that needs continuity SHOULD retain the key it first verified and treat a later change as an event to be confirmed outside resolution.

Revocation Not Observable Because no revocation surface is specified (Section 5.4), a resolver cannot learn that a DID has been deactivated. A compromised key continues to resolve as valid until the record is replaced, and a replacement by the attacker is indistinguishable from a rotation (Section 7.2). A relying party MUST NOT treat a successful resolution as evidence that the DID has not been deactivated, and SHOULD bound the reliance it places on a did:alter signature accordingly.

Spelling Equivalence The method has a canonical spelling and a display spelling of the same DID (Section 3.2). A resolver or relying party that compares, caches or authorises on a string it has not normalised can be given two spellings that it treats as two principals, or a cached result for one that it fails to apply to the other. Section 3.4 requires normalisation before every comparison and cache lookup for this reason.

Handle-Domain Confusion and Instrument Handles A handle spelled like a domain name carries no DNS meaning (Section 3.5). An Instrument-tier handle names no principal and resolves to nothing (Section 5.2). A relying party that renders a did:alter DID to a person SHOULD render the handle with its leading tilde, as requires of handles.

No Fallback A resolver that cannot complete recognition returns an error. It does not consult a mirror, a cache past its bound, or an unvalidated lookup, because each of those would let an attacker who can disrupt DNS for the zone choose what the resolver returns.

Privacy Considerations

A DID Is a Correlator A did:alter DID is stable and public. Every credential, signature and presentation that carries it can be linked to every other that carries it, and to the handle. Linkability is the purpose of a handle, and it is unsuitable where a subject needs presentations that cannot be linked. This document defines no pairwise or per-relying-party identifier. A subject who needs one SHOULD use an identifier from a method designed for unlinkability, and a credential issuer SHOULD NOT make a did:alter DID the subject of a credential the subject did not choose to make linkable.

Publication in DNS Resolution reads a public DNS record. Section 7.1.1 of gives three reasons a per-individual envelope in DNS is NOT RECOMMENDED: the zone can be enumerated, the record set grows with the handles it holds, and a published record cannot be recalled from caches and passive collectors. Each applies to a did:alter DID naming a natural person. A person who requires concealment MUST NOT publish an envelope, and so cannot hold a did:alter DID under this document. The method suits organisations, Bot-tier handles, and individuals who choose public publication with that understanding.

Query Metadata A resolver querying _alter.<zone> reveals to its recursive resolver which DID it is resolving. Resolvers SHOULD use DNS over HTTPS or DNS over TLS where operationally feasible.

Revocation Linkage The rev value is a hash commitment and discloses nothing during the envelope's life. A reveal links the pre-image to the DID at the moment of revocation only .

IANA Considerations This document has no IANA actions. Method names for Decentralized Identifiers are recorded in the W3C DID method registry , not by IANA. Registration of the method name alter there has not been requested.

Open Issues This section is removed before publication as an RFC.

1. The display form in other documents. writes did:alter DIDs in the display form, with the literal "~". Because this document makes the percent-encoded form canonical (Section 3.2), a DID carried in a commit trailer is converted before comparison. Whether should carry the canonical form on the wire is for its next revision.
2. Zoneless identifiers. writes did:alter DIDs with no zone. Under and such an identifier names no zone and resolves only through an association held out of band. A DID that only some resolvers can resolve falls short of what expects of a method's read operation.
3. Key history. Section 6 records that the envelope carries one key and no identifier, while expects historical keys to be retrievable by fragment.
4. Revocation surface. Deactivation cannot be observed until a revocation surface is specified (Section 5.4).
5. Natural persons. The DNS substrate is NOT RECOMMENDED for per-individual publication (Section 8.2). A means of resolving a person's handle without publishing it in DNS would change who can hold a did:alter DID, and is outside this document.
6. Identifiers with no handle. This document admits only identifiers built on a handle (Section 3.2). An identifier derived from a hash for a pseudonymous subject, one carrying an internal account number, and a fixed name for an issuing service all have no envelope to resolve, so none is a did:alter DID, and a resolver returns invalidDid for each. A pseudonymous subject is better named by a method that needs no registry, and an issuing service by its own handle. Admitting them would add identifiers no resolver can read, the shortfall item 2 already records. Whether the method should define a pairwise pseudonymous form of its own, resolvable without revealing the subject behind it, is open.

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] 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] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Alter Meridian Pty Ltd Alter Meridian Pty Ltd Informative References This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Alter Meridian Pty Ltd

Document History

• draft-morrison-did-alter-method-00 (2026-10-05): first version.
• draft-morrison-did-alter-method-00 (2026-10-19): prose rewritten against the drafting rules, and every citation of another draft in the stack pinned to its latest posted revision.
• draft-morrison-did-alter-method-00 (2026-10-21): citations of other drafts in the stack moved to the revisions going up with this one, and the cross-references and wording checked.

Acknowledgments None yet.