5 Technical Specifications

5.1 DID Document Design Principles

The AMT protocol employs did:amt for distributed identifier generation and resolution. The DID Document structure is minimal and stateless:

DID := did:amt:H(DIDDoc)

DIDDoc := {
  id: DID,
  publicKey: PublicKey,
  metadata: Metadata
}

where \(H\) is SHA3-512 (collision-resistant hash function).

5.1.1 Critical Design Decision: Abolition of serviceEndpoint

Traditional DID specifications include serviceEndpoint in DIDDocuments. The AMT protocol rejects this for principled reasons:

Problem with serviceEndpoint

• Short lifetime: Service endpoint contracts last months to few years

• Individual burden: Users must manage contract renewals and provider changes

• Unrealistic assumption: Assumes individual can maintain stable, contracted endpoints

• Real-world failure: When provider fails or service terminates, users cannot migrate

AMT Solution

Remove serviceEndpoint from DIDDocument entirely.

Instead:

• DID lifetime: Long-term (public-key-based, years to decades)

• Endpoint lifetime: Session-scoped (minutes to hours)

• Endpoint management: Service provider responsibility only

• Individual burden: Zero

Implementation Reality

• Wallet is invoked by service app (already knows its own endpoint)

• DIDDocument contains only public key for cryptographic verification

• Endpoint information implicit in application context

• No distributed endpoint discovery needed

For complete did:amt specification details, see Chapter 2 (did:amt Method Specification).

5.2 DIDComm Integration

AMATELUS employs DIDComm Messaging v2.1 as the sole communication protocol.

5.2.1 Message Structure

DIDCommMessageSend := {
  senderDID: ValidDID,
  senderDoc: Option<ValidDIDDocument>,
  vcs: List<ValidVC>,
  zkp: Option<ValidZKP>
}

5.2.2 Security Properties

• ECDH-1PU authenticated encryption: Sender identity authenticated exclusively to recipient

• Message-level security: Independent of transport layer

• Transport agnosticism: Works over HTTPS, BLE, WebSocket, etc.

• Sender anonymity (optional): Anoncrypt layer available if needed

5.3 Verifiable Credentials

5.3.1 VC Structure

VC := {
  issuer: DID_issuer,
  subject: DID_subject,
  claims: Claims,
  signature: Signature,
  credentialStatus: RevocationInfo,
  deLinkageInfo: Option<DeLinkageInfo>
}

5.3.2 Delinkage Information

To prevent cross-service correlation:

DeLinkageInfo := {
  identityDID: DID,        // Long-term identity DID
  communicationDID: DID    // Session-specific DID
}

ZKP proves ownership of both DIDs without revealing either to external parties.

5.4 Zero-Knowledge Proofs

5.4.1 Security Guarantees

AMATELUS provides cryptographic proof generation and verification. Impersonation attacks are prevented through DIDComm’s requirement for explicit public key transmission.

5.4.2 Replay Prevention (Application Layer Responsibility)

Important: Replay prevention (preventing legitimate users from reusing the same ZKP across multiple sessions) is NOT part of AMATELUS protocol. This is an application-layer responsibility.

Services that require single-use ZKP semantics (e.g., one-time registrations, authorization grants) should:

• Implement nonce-based mechanisms in their application layer

• Generate unique session nonces for each verification request

• Record and verify nonce freshness (checking that the nonce has not been used before)

• Maintain nonce history within their application database

Services where ZKP reuse is acceptable (e.g., age verification for each transaction) do not require nonce mechanisms.

Important: AMATELUS does not specify or enforce nonce handling. This is entirely the responsibility of the application implementing the protocol.

5.4.3 Computational Efficiency

• Offline precomputation: Heavy circuit evaluation (minutes to hours)

• Real-time verification: Light operations only (milliseconds to hundreds of milliseconds)

• UX compatibility: User interaction completes within tolerance (3 seconds)