AMATELUS Protocol Spec

8 Privacy Architecture

Definition 19
#

This chapter covers privacy architecture aspects of AMATELUS.

8.1 Anti-Linkability Across Services

Multiple DIDs enable cross-service unlinkability:

For all DID_1, DID_2, Service_1, Service_2:
  (Service_1 != Service_2) AND
  Link(DID_1, DID_2) requires 2^128 quantum operations

8.2 Zero-Knowledge Property

ZKP reveal attribute ownership without revealing identity:

  • Public: Attribute claimed (age \(\geq \) 18)

  • Hidden: Identity proving the attribute

  • Hidden: Secret key generating the proof

  • Verified: ZKP authenticity via public key

8.2.1 Privacy Preservation Under DIDComm

A critical design question: How can DIDComm’s requirement for explicit public key transmission (for impersonation prevention) coexist with privacy protection?

Theorem 20
#

Privacy is maintained despite public key transmission via DIDComm due to:

  • Ephemeral Communication DIDs: Each session uses distinct DIDs with different key pairs

  • Different services, different keys: User generates new keys for each service

  • Cryptographic unlinkability: Public keys from different sessions cannot be linked (requires \(2^{128}\) quantum operations to link, assuming quantum-resistant hash functions)

  • Service-specific communication DIDs: Verifier knows only the communication DID, not the user’s persistent identity DID

Result: While DIDComm requires public key disclosure for impersonation prevention, the use of ephemeral DIDs with distinct key pairs per service ensures cross-service unlinkability and privacy.

8.2.2 Application-Layer Privacy Considerations

Applications using AMATELUS should consider additional privacy measures:

  • Session management: Create new communication DIDs for each session to prevent cross-session linkability

  • Retention policies: Do not retain communication DIDs or ZKPs longer than necessary

  • Logging: Minimize logging of ZKPs and DIDDocuments; log only what is necessary for application function

  • Nonce handling: If implementing nonce mechanisms (application responsibility), handle nonce values with privacy in mind

8.3 Deniable Authentication

For privacy-sensitive scenarios, anonymous encryption (Anoncrypt) available:

  • Sender identity hidden from intermediaries

  • Recipient verifies proof authenticity (still authenticated)

  • Sender maintains plausible deniability