The did:alter Decentralized Identifier Method

Internet-Draft	The did:alter DID Method	October 2026
Morrison	Expires 24 April 2027	[Page]

Abstract

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

1. Introduction

A ~handle is a textual identity reference with a tier read from its lexical form [ALTER-URI]. 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 [RFC4033] and checking the envelope signature [MCPDNS]. The alter: URI is the dispatchable form of the same reference for operating-system handlers.¶

Software built on Decentralized Identifiers [DID-CORE] 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 [ALTER-URI] 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 [MCPDNS] (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 [MCPDNS] 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.¶

2. 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 [RFC2119] [RFC8174] 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 [DID-CORE].¶
~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 [ALTER-URI].¶
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 [ALTER-URI].¶
Envelope: The signed identity record retrieved from _alter.<zone>, with the seven required fields v, h, pk, ilr, ts, rev and sig [MCPDNS].¶
Recognition: The procedure of [MCPDNS] 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.¶

3. Method-Specific Identifier

3.1. Method Name

The method name is alter. A DID that uses this method begins with the string did:alter:, in lowercase, as [DID-CORE] requires.¶

3.2. Syntax

The method-specific identifier carries a handle and, optionally, the zone that publishes it. The following ABNF [RFC5234] defines it. handle-name and org-scope are the productions of the same names in Section 3.3 of [ALTER-URI], imported without change.¶

alter-did      = "did:alter:" alter-msid
alter-msid     = tilde handle-name [ at zone ]

tilde          = "~" / "%7E"
                 ; the handle prefix of [ALTER-URI]
at             = "@" / "%40"
                 ; introduces the zone, as "@" introduces
                 ; org-scope in [ALTER-URI]
zone           = org-scope
                 ; the publishing zone, at most 253 octets

alter-did-url  = alter-did [ "#" key-fragment ]
key-fragment   = "key-" 1*DIGIT
                 ; names the verification method of Section 4

The percent-encoded spelling [RFC3986], %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 [DID-CORE], 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 [IDCOMMITS] 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 [DID-CORE].¶

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

3.3. Examples

did:alter:%7Ealice%40alice.example
did:alter:%7Eacme%40acme.example
did:alter:%7Ecarol%40carol.acme.example
did:alter:%7Ealice%40alice.example#key-1767225600
did:alter:%7Ealice

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 [IDCOMMITS], 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 [ALTER-URI] is the display form with the did: prefix dropped, for example alter:~alice@alice.example.¶

3.4. 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 [ALTER-URI] nor [MCPDNS] 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.¶

3.5. 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 [ALTER-URI] 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.¶

4. The DID Document

A resolver that has a verified envelope for the requested handle produces a DID document in the JSON representation of [DID-CORE], 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 [CID]:¶

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 [RFC7517] of the Octet Key Pair type defined by [RFC8037], 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 [RFC8037].¶

{
  "id": "did:alter:%7Ealice%40alice.example",
  "controller": "did:alter:%7Ealice%40alice.example",
  "alsoKnownAs": ["alter:~alice@alice.example"],
  "verificationMethod": [{
    "id": "did:alter:%7Ealice%40alice.example#key-1767225600",
    "type": "JsonWebKey",
    "controller": "did:alter:%7Ealice%40alice.example",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
    }
  }],
  "authentication":
    ["did:alter:%7Ealice%40alice.example#key-1767225600"],
  "assertionMethod":
    ["did:alter:%7Ealice%40alice.example#key-1767225600"]
}

The document is JSON [RFC8259]. 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 [XMLSCHEMA] in UTC, and with deactivated set to true only as Section 5.4 provides.¶

5. Operations

5.1. 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:¶

generates an Ed25519 key pair and a secret revocation pre-image;¶
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 [MCPDNS] specifies;¶
publishes the envelope as the TXT record at _alter.<zone> in a DNSSEC-signed zone, holding the envelope of that one handle only, as [MCPDNS] 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 [ALTER-URI], no did:alter DID is created for one.¶

Section 7.1.1 of [MCPDNS] 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.¶

5.2. Read (Resolve)

Given a did:alter DID, a resolver MUST perform these steps in order.¶

Parse. Parse the DID against Section 3.2. On failure, return invalidDid. Normalise it per Section 3.4.¶
Tier. If handle-name is Instrument-tier, return notFound. An Instrument-tier handle names no independent principal [ALTER-URI], and a resolver MUST NOT return a DID document for one.¶
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 [ALTER-URI] allows for a URI with no org-scope; otherwise it returns notFound. The zone is never derived from the handle (Section 3.5).¶
Recognise. Run the envelope recognition procedure of [MCPDNS] 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.¶
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 [MCPDNS] provides, and the resolver MUST NOT report the DID as not deactivated on the strength of a check it did not perform.¶
Build. Build the DID document of Section 4 from the verified envelope.¶
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 [MCPDNS] 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.¶

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

5.4. 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 [MCPDNS] 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. [MCPDNS] holds that absence of the record is indistinguishable from misconfiguration and is never revocation. A resolver that finds no record returns notFound, never deactivated.¶

[MCPDNS] 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 [MCPDNS] therefore cannot observe deactivation, and Section 7.3 sets out the consequence.¶

7. Security Considerations

The security considerations of [MCPDNS] and of [ALTER-URI] apply in full. The following are specific to using the envelope as a DID.¶

7.1. 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 [DID-WEB]. 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.¶

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

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

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

7.5. 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 [ALTER-URI] requires of handles.¶

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

8. Privacy Considerations

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

8.2. Publication in DNS

Resolution reads a public DNS record. Section 7.1.1 of [MCPDNS] 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.¶

The display form in other documents. [IDCOMMITS] 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 [IDCOMMITS] should carry the canonical form on the wire is for its next revision.¶
Zoneless identifiers. [IDCOMMITS] writes did:alter DIDs with no zone. Under [ALTER-URI] and [MCPDNS] 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 [DID-CORE] expects of a method's read operation.¶
Key history. Section 6 records that the envelope carries one key and no identifier, while [IDCOMMITS] expects historical keys to be retrievable by fragment.¶
Revocation surface. Deactivation cannot be observed until a revocation surface is specified (Section 5.4).¶
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.¶
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.¶

11. 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>.
[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>.
[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>.
[RFC7517]: Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC8037]: Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/info/rfc8037>.
[RFC8259]: Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[DID-CORE]: "Decentralized Identifiers (DIDs) v1.0", 19 July 2022, <https://www.w3.org/TR/did-core/>.
[XMLSCHEMA]: "W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes", 5 April 2012, <https://www.w3.org/TR/xmlschema11-2/>.
[CID]: "Controlled Identifiers v1.0", 2025, <https://www.w3.org/TR/cid-1.0/>.
[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/>.
[ALTER-URI]: Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", Work in Progress, Internet-Draft, draft-morrison-alter-uri-scheme-05, 2026, <https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/>.

The did:alter Decentralized Identifier Method

Abstract

Status of This Memo

Copyright Notice

Table of Contents