AMATELUS Protocol Spec

3 did:amt Method Specification

3.1 Abstract

Definition 6
✓
#

Uses

Lean declarations

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
✓
#

Uses

Lean declarations

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

The generation process consists of:

  1. Generate Ed25519 key pair

  2. Prepare information pair: AMT Version Number + Public Key

  3. Select DID Document template corresponding to AMT version

  4. Derive DID through local cryptographic operations

3.3.2 Read: Local Resolution

Theorem 8
✓
#

Uses

Lean declarations

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.

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

3.5 Future Evolution: PQC Transition

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 Example: Version 0 DID Document

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:amt:0V3R4T7K1Q2P3N4M5J6H7G8F5D4C3B2A...",
  "verificationMethod": [{
    "id": "did:amt:0V3R4T7K1Q2P3N4M5J6H7G8F5D4C3B2A...#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:amt:0V3R4T7K1Q2P3N4M5J6H7G8F5D4C3B2A...",
    "publicKeyMultibase": "k3t635r7r1c0kdf41n2p5h3t2d3n2g5r..."
  }],
  "authentication": ["#key-1"],
  "assertionMethod": ["#key-1"]
}