Dependencies

The AMATELUS protocol is a cryptographic authentication mechanism integrating:

• Decentralized Identifiers (DIDs)

• Verifiable Credentials (VCs)

• Zero-Knowledge Proofs (ZKPs)

AHI is an optional, category-scoped identifier derived from issuer-certified private attributes in a resident credential.

This chapter covers trust chain architecture aspects of AMATELUS.

AMATELUS relies on the following cryptographic security assumptions:

• Collision-resistant hash: SHA3-512 provides 128-bit security against quantum adversaries

• Unforgeable signatures: Dilithium2 provides 128-bit security against quantum adversaries

• ZKP soundness: Standard zero-knowledge properties (completeness, soundness, zero-knowledge)

This chapter covers deployment models aspects of AMATELUS.

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.

This chapter covers implementation guidance aspects of AMATELUS.

This chapter covers secret key lifecycle management aspects of AMATELUS.

This chapter covers multi-device support aspects of AMATELUS.

This chapter covers privacy architecture aspects of AMATELUS.

A Merkle inclusion proof establishes membership in an issuer-authenticated active-credential snapshot. It does not by itself establish current validity.

This chapter covers formally verifiable json schema subset aspects of AMATELUS.

This chapter covers technical specifications aspects of AMATELUS.

This chapter covers trust architecture aspects of AMATELUS.

AMATELUS delivers the following cryptographic capabilities:

• Public key infrastructure (PKI) based distributed identifiers

• Zero-knowledge proof-based attribute ownership verification

• Verifiable credentials for claim issuance and storage

• Cryptographic trust guarantees

AMATELUS does not provide:

• Centralized directory services (DID resolution is local-only)

• Mediation or relay infrastructure

• User authorization decisions

• Communication endpoint management

• Message delivery guarantees

AMATELUS is a cryptographic authentication mechanism, not a communication infrastructure.

Man-in-the-Middle attacks are mitigated at the transport layer.

While AMATELUS provides cryptographic identity verification, ECDH-1PU authenticated encryption and TLS/HTTPS are the responsibility of service providers.

Replay prevention combines service-owned challenge state with protocol-enforced binding of the proof to the expected presentation context.

Important distinction:

• Impersonation attacks (attacker with different secret key): require authenticated transport plus claim/subject/key/context binding

• Replay attacks (legitimate user reusing same ZKP): implemented by the service. Interactive and AHI profiles require fresh challenges; AMATELUS proof verification must enforce the expected context binding.

Interactive/authorization profiles must implement challenge handling at the application layer:

• Generate unique session nonces for each verification

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

• Maintain nonce history in application database

An explicitly reusable attestation may omit fresh-session semantics. Interactive age checks, permission checks and one-time grants require fresh challenges.

Multiple DID possession is intentional protocol design for privacy protection.

While a single entity can control multiple DIDs, Anonymous Hash Identifiers (AHI) restrict per-audit-domain abuse through cryptographic binding to national identity systems.

The boundary between cryptographic verification (AMATELUS responsibility) and service provision (service provider responsibility) eliminates distributed infrastructure complexity while preserving cryptographic security properties.

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

The generation process consists of:

1. Generate an Ed25519 key pair. Keep the private key on the owner’s device.

2. Prepare the pair \([0, PK]\), where \(PK\) is the 32-byte public key.

3. Select the fixed Version 0 pre-DID template shown below.

4. Encode \(PK\) with Crockford’s Base32 and prepend k; insert it into publicKeyMultibase.

5. Serialize the entire template with JCS (RFC 8785) to UTF-8 without a BOM or trailing newline, then hash those bytes with SHA3-512.

6. 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.

7. Only now populate the final document’s id, the verification method’s controller, and its id (DID plus #key-1).

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.

A valid presentation binds original signed attributes and, if requested, the AHI to one underlying subject. It additionally proves knowledge of the presentation key and its direct, issuer-approved same-subject, or delegated relationship to that subject. Delegation preserves the principal/proxy roles.

Under signature unforgeability and proof soundness, verify both communication key control and the signed claim’s relationship to that presenter. A known public key alone does not connect an independently valid attribute proof to its sender. Issuer-approved subject links and the expected request context must also be checked.

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.

The presentation context includes the verifier, requested predicate, session challenge and purpose. The verifier compares this context with its own request. Separate proofs must establish a shared secret subject through a session-scoped commitment or an equivalent composition relation. Different DID strings may represent the same subject; no permanent common public identifier is required.