3 did:amt Method Specification

3.1 Abstract

This chapter restores the Version 0 did:amt draft’s template-based derivation. It is a draft method specification, not a W3C Standard. The exact byte encoding and JCS choice below make the draft’s illustrative choices deterministic for this repository; previously published identifiers must be checked against this profile before migration. They must not be silently reinterpreted.

Definition 6

✓

The did:amt method is a Decentralized Identifier (DID) that is algorithmically generated and resolved without reliance on any external Verifiable Data Registry (VDR) such as a blockchain. This method is designed for high-stakes environments (public administration, government) where data integrity and operational robustness are paramount.

3.2 did:amt Syntax

The did:amt syntax conforms to the W3C DID Core specification:

did-amt              := "did:amt:" method-specific-id
method-specific-id   := crockford-base32-encoded-sha3-512-hash

The method-specific-id is a Crockford’s Base32 encoded string of the hash value generated through the local creation process.

3.2.1 Crockford’s Base32 Character Set

0123456789ABCDEFGHJKMNPQRSTVWXYZ

This character set is chosen to minimize human transcription errors in administrative settings (e.g., avoiding confusion between O and 0, or I and l).

3.3 CRUD Operations

3.3.1 Create: Local Generation

Theorem 7

✓

A did:amt identifier is generated locally on the owner’s device without network registration.

The generation process consists of:

Generate an Ed25519 key pair. Keep the private key on the owner’s device.
Prepare the pair \([0, PK]\), where \(PK\) is the 32-byte public key.
Select the fixed Version 0 pre-DID template shown below.
Encode \(PK\) with Crockford’s Base32 and prepend k; insert it into publicKeyMultibase.
Serialize the entire template with JCS (RFC 8785) to UTF-8 without a BOM or trailing newline, then hash those bytes with SHA3-512.
Encode the 64-byte digest with Crockford’s Base32 and prepend did:amt:. The version is a template selector, not a digit prepended to the digest.
Only now populate the final document’s id, the verification method’s controller, and its id (DID plus #key-1).

3.3.2 Version 0 Pre-DID Template

The following object is the hash input before JCS serialization. In particular, it has no document id, verification-method id, or controller. It is a generation template, not a complete DID Document. The encoded public key is the only variable field. No service, metadata, extra key, or additional property is permitted in this version’s template.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "verificationMethod": [{
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "<encoded-public-key>"
  }],
  "authentication": ["#key-1"],
  "assertionMethod": ["#key-1"]
}

JCS (https://www.rfc-editor.org/rfc/rfc8785) sorts object member names and emits no insignificant whitespace. For this fixed ASCII template, the top-level order is @context, assertionMethod, authentication, and then the verification-method array; the inner order is publicKeyMultibase, type. Array order is preserved. All of these fields are included in the hash. AMT.templateV0 emits exactly these canonical bytes, rather than implementing a general-purpose JSON canonicalizer.

Byte encoding profile.

Bytes are read most-significant bit first in their original order and grouped into five-bit symbols. The last group is padded on the right with zero bits; there is no = padding. Leading zero bytes are preserved. Canonical output uses the uppercase alphabet above: 32 bytes produce 52 characters and 64 bytes produce 103. Wire decoding rejects aliases, lowercase, separators, noncanonical trailing bits, and incorrect key lengths. A human-entry interface may normalize input before canonical wire validation.

Draft codec compatibility.

The draft stores its k-prefixed Crockford encoding in the public-key field. This repository preserves that draft convention explicitly. It is not standard multibase: the registered k prefix means base36, not Crockford’s Base32 (see the multibase registry at https://github.com/multiformats/multibase/blob/master/multibase.csv). Generic multibase decoders and standard Ed25519 verification-method implementations must not be assumed to interoperate with this draft encoding. A standards-compatible encoding change requires a separately specified version and new derivation vectors.

3.3.3 Read: Local Resolution

Theorem 8

✓

The resolution of a did:amt is completed locally by a verifier.

No external Verifiable Data Registry (blockchain, centralized service) or network calls are required. Verifier receives the [AMT Version Number, Public Key] pair from the owner and executes the same local derivation steps for verification. Unsupported versions and incorrect public-key lengths are rejected. The claimed DID must equal the recomputed DID. If a completed document is supplied, every field and reference must match the generated Version 0 document; it is not sufficient to extract its first key and trust its other fields. Wire parsing must validate the fixed @context and reject duplicate or extra JSON members. The Lean W3C model keeps that fixed context implicit and stores relationship references as resolved DID URLs. Key possession is checked separately by the protocol.

3.3.4 Update: Not Supported

As did:amt DID Documents are immutable, Update operations are not supported. Key rotation is handled by issuing a new DID and linking it via a “DID Continuity Verifiable Credential” issued by a trusted third party.

3.3.5 Deactivate: Key Destruction

There is no explicit Deactivate operation. Deactivation is effectively achieved by destroying the associated private key.

3.4 Cryptographic Properties

3.4.1 DID Identifier Security

Hash function: SHA3-512 (post-quantum collision resistance)
Security level: 256-bit (quantum-resistant)
Uniqueness: Permanent uniqueness guaranteed by collision resistance

3.4.2 DID Ownership Proof

Signature algorithm: Ed25519 (current version)
Security level: 128-bit (classical only, see future evolution)
Signature verification: Public key validation against DID Document

3.4.3 Privacy

The avoidance of a Verifiable Data Registry (VDR) ensures that:

DIDs are not publicly enumerable
No central authority records DID creation
High degree of privacy maintained

3.4.4 Operational Robustness

Crockford’s Base32 encoding minimizes human transcription errors during manual entry in administrative processes. The source draft strongly recommends an optional checksum. This is a human-transcription envelope, not part of the canonical DID, public-key field, or hash input. A checksum algorithm and its presentation syntax must be specified by that envelope’s profile; Version 0 here does not invent one.

3.5 Future Evolution: PQC Transition

This section is informative and is not part of the normative Version 0 profile.

3.5.1 Versioning for Cryptographic Agility

The AMT protocol is designed with “cryptographic agility,” allowing for the upgrade of its cryptographic suite through versioning.

3.5.2 Foreseeable Changes (AMT v1+)

Post-Quantum Signature Migration

The most critical change will be migration from Ed25519 to a NIST-selected PQC signature algorithm (e.g., CRYSTALS-Dilithium). This ensures DID ownership proof is also secure against quantum computers.

Binary Data Format Challenge

PQC signature algorithms require significantly larger public key and signature sizes (several to tens of kilobytes). Future versions will likely specify a binary representation format such as CBOR (Concise Binary Object Representation) for DID Documents to maintain efficiency.

Interoperability Through Versioning

The AMT Version Number presented by the owner allows verifiers to accurately determine:

Which cryptographic algorithms to use (Ed25519 vs PQC)
Which data formats to expect (JSON-LD vs CBOR)
Secure interoperability during transition periods

3.5.3 Reproducible Version 0 Example

The source draft’s encoded strings were illustrative placeholders. The following vector is calculated from its actual example public key using this chapter’s explicit byte profile and JCS template. Line breaks in the displays are for printing only and are not part of any value.

Public key (hex, 32 bytes):
d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a

Encoded public key (k plus 52 symbols):
kTXD9G0C2P45BFNABZV9WJS07787E2WQKVAK269DF08D6HXR7A4D0

SHA3-512 digest (hex, concatenate both lines):
103af18537e4e9944bc6b34067f3c6ffa3351dfbcec7f48cb271f6845b9895cf
3fc954b080e72200cf2d5df5ee2f111000f7b766a28233b50cbbda0b56d703c2

DID (concatenate both lines):
did:amt:20XF319QWKMS8JY6PD06FWY6ZYHKA7FVSV3Z935JE7V88PWRJQ7K
ZJAMP20EE8G0SWPNVXFE5W8H007QPXKA50HKPM6BQPGBAVBG7GG

The complete document has the following structure. Replace <DID> and <KEY> with the values above; placeholders are not literal wire values. The root has no controller; the verification method has one.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "<DID>",
  "verificationMethod": [{
    "id": "<DID>#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "<DID>",
    "publicKeyMultibase": "<KEY>"
  }],
  "authentication": ["#key-1"],
  "assertionMethod": ["#key-1"]
}

Formal model boundary.

AMT.deriveWith and AMT.verifyWith take an explicit SHA3-512 backend and reject digest lengths other than 64 bytes. They implement the local derivation and completed-document checks. Existing protocol proofs use hashForDID, which is an abstract placeholder, not an executable SHA3-512 implementation. Their success does not establish hash security or validate the numerical digest above. Regression examples check the canonical input and the output transformation against an independently calculated vector, with a fixture backend explicitly distinguished from real cryptography.

3.6 Version 1: Explicit DIDComm Key Agreement Profile

Version 0 is unchanged and remains a signing-only draft profile. It must not be silently reinterpreted as providing a DIDComm encryption key. This repository adds Version 1 for encrypted transport. It uses an independently generated Ed25519 signing key and X25519 agreement key, each 32 public-key bytes. The public information pair becomes \([1,\{ PK_{sign},PK_{agree}\} ]\). No private key is shared, and no conversion between Ed25519 and X25519 is assumed. Existing identity VCs may keep their Version 0 subject while an authenticated communication DID uses Version 1; personal-subject links still require the existing authorization checks.

Both public keys are included in the fixed template before hashing. The context array is exactly the DID Core v1 context followed by https://w3id.org/security/suites/jws-2020/v1. The template has authentication and assertion-method references to #sign-1, and a key-agreement reference to #agree-1. Its verification-method array contains these two objects, in signing-key then agreement-key order:

{
  "publicKeyJwk": {
    "crv": "Ed25519", "kty": "OKP", "x": "<signing-x>"
  },
  "type": "JsonWebKey2020"
}
{
  "publicKeyJwk": {
    "crv": "X25519", "kty": "OKP", "x": "<agreement-x>"
  },
  "type": "JsonWebKey2020"
}

Each x value uses unpadded base64url of the exact 32 public-key bytes. The complete object is JCS-serialized and SHA3-512-hashed; the digest uses the same Crockford encoding and DID prefix as Version 0. Only afterwards are root id, method ids and method controllers filled. No service endpoint or external registry is introduced. The method ids end in #sign-1 and #agree-1, respectively. Unknown versions, wrong key lengths, changed keys and altered relationships are rejected. JSON parsing validates the exact context array and all supported fields. The Lean AMT.DIDComm.template is the exact canonical template definition.

This is a new repository profile, not a claim that the original paper already specified X25519. Future PQC profiles require further versions. Changing either public key changes the hash input and requires a newly derived DID; existing DIDs are not edited. Test vectors use independent Python SHA3-512 calculations, while Lean injects that result through an explicitly labelled fixture backend.

DIDComm processing.

The local resolver reconstructs the peer document and verifies its full shape. Only the X25519 key referenced by keyAgreement can be selected for ECDH-1PU; skid and recipient kid must resolve to those exact method ids. Signing-key references are rejected for encryption. The backend verifies that its private-key handle corresponds to the selected key, rejects invalid X25519 inputs and all-zero shared secrets, and authenticates protected headers, from/to and presentation context before returning plaintext. These are explicit backend contracts, not cryptographic implementations in Lean. The wire entry points are Network.sendViaDIDComm and Network.receiveViaDIDComm; older message-flow examples are named MessageModel and make no encryption claim. The profile follows DIDComm’s key-selection requirements: https://identity.foundation/didcomm-messaging/spec/v2.1/.

Reproducible two-key vector.

Use the Version 0 example’s Ed25519 key and X25519 public bytes 09 followed by 31 zero bytes (a public test fixture, not a production key-generation recipe). The expected SHA3-512 digest is:

84a35be43f3898f2d60bf579eb9cc3be86abe255dcc800fcb74f21bb36c14f6b
2d34218b8392508f413efb3a2d28017ad0deb92d557279649a05a8a17f004fa7

The expected DID is (concatenate the lines):

did:amt:GJHNQS1Z72CF5NGBYNWYQ763QT3AQRJNVK401Z5Q9WGVPDP19XNJ
TD11HE1S4M4F84ZFPEHD500QNM6YQ4PNAWKSCJD0BA51FW04Z9R