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:

PreDID := Template(version, EncodePublicKey(publicKey))
Digest := SHA3-512(JCS(PreDID))
DID := "did:amt:" || CrockfordBase32(Digest)
DIDDoc := Finalize(PreDID, DID)

The pre-DID template contains no DID or controller self-reference. Only after hashing are those fields filled in the completed document. Version 0 uses the exact fixed template and encoding in Chapter 3; arbitrary metadata is not part of that template. A received completed document must match local reconstruction.

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

DIDComm authenticates a communication key. Sending a public key alone does not prove that an attribute credential or AHI belongs to that key’s controller.

5.4.2 Session Freshness Profiles

Interactive authentication, AHI registration, benefits and authorization require a fresh verifier challenge bound into the proof, with service-side expiry and replay tracking. A holder nonce may additionally be used; hashing a nonce without binding and checking the expected request is insufficient. A deliberately reusable attestation profile must state that it does not establish fresh presenter presence. The service owns challenge generation/storage; proof verification enforces context binding. Session freshness and revocation-snapshot freshness are separate properties.

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)