11 Trust Chain Architecture

11.1 Overview

The Trust Chain specification provides a hierarchical delegation mechanism that enables authority transfer through cryptographically verified credentials. Key capabilities include:

• Authority Delegation: Upper organizations delegate authority to lower organizations

• Cryptographic Verification: Delegation chains are cryptographically verifiable

• Schema-Based Delegation: Delegation content is structurally defined using JSON Schema

• Dynamic Depth Limitation: Delegators specify maxDepth; Nat monotonic decrease prevents infinite hierarchies

• Holder-Centric Design: VCs can be issued by anyone (including Holders themselves); verifiers check only the delegation chain’s grantorDID

• Per-Claim Signatures: Recipients sign each claim individually, dramatically reducing VP/ZKP input sizes

• ZKP-Only Submission: VPs are internal structures; all submissions use only ZKPs

• Field-Level Selective Disclosure: ZKPs enable revelation of only required fields, maximizing privacy

11.2 Trust Chain Components

11.2.1 Architecture

A trust chain flows from a root authority through delegatees to holders:

Root Anchor (Trusted Authority)
    v Delegation Credential
    | (delegated authority -> recipient)
    v
Delegatee (Authority)
    v Attribute Credential
    | (claim with embedded delegation)
    v
Holder (Subject)
    v Re-packaging (optional)
    | (Holder re-issues with own signature)
    v
Verifier (Service Provider)
    verifies:
    - ZKP validity
    - grantorDID in trustedAnchors
    does NOT verify:
    - VC issuer
    - granteeDID matching

11.2.2 Critical Design Principles

• VC Issuer Flexibility: The issuer field can be anyone; trust derives from the delegation chain’s grantorDID

• Delegation Chain Focus: Verifiers inspect grantorDID (trust root), not issuer

• ZKP Compatibility: VCs issued by Holders can still prove delegated authority via ZKP

• Holder Re-packaging: Holders can re-issue received VCs with their own signature; each claim’s proof remains unchanged

11.3 Delegation Credentials

11.3.1 Structure

A Delegation Credential contains multiple delegations, each authorizing a specific claim type:

• issuer: Delegator’s DID (must be in trustedAnchors)

• credentialSubject.id: Original recipient’s DID (historical information)

• credentialSubject.delegations: Array of delegation objects

• proof: Delegator’s signature over the entire credential

Each delegation element contains:

• grantorDID: Authority granting the right (verification anchor)

• granteeDID: Initial recipient DID (historical information)

• label: Human-readable claim label (e.g., “Resident Certificate”)

• claimSchema: JSON Schema (AMATELUS Subset) defining allowed claim structure

• maxDepth: Maximum further delegation depth (Nat \(\geq 1\))

• proof: Delegator’s signature over the delegation object

11.3.2 Dynamic Depth Limitation

The protocol prevents infinite delegation chains through monotonic depth decrease:

1. Each delegator specifies maxDepth (maximum delegations from this point forward)

2. Each recipient computes: nextDepth = min(parentDepth - 1, delegation.maxDepth)

3. When depth reaches zero, further delegation is impossible

4. Lean 4 formally proves termination via termination_by clause

Example: Government \(\xrightarrow {\text{maxDepth}=5}\) Prefecture \(\xrightarrow {\text{maxDepth}=2}\) Municipality \(\xrightarrow {\text{maxDepth}=1}\) Department \(\xrightarrow {\text{maxDepth}=0}\) (chain stops)

11.4 Attribute Credentials with Embedded Delegation

11.4.1 Direct Issuance (0-Layer)

Standard W3C VC issued directly by a trusted authority:

• No delegation chain

• Simple structure: issuer, credentialSubject.claims, proof

• Verification: issuer must be in trustedAnchors

11.4.2 Delegated Issuance (1-Layer and Beyond)

When issued under delegated authority, each claim embeds delegation information:

• content: Actual claim data

• delegation: Reference to the delegation authorization

• delegationProof: Grantor’s signature over the delegation

• proof: Grantee’s signature over the content (prevents Holder modification)

Verification checks:

1. delegation.grantorDID is in trustedAnchors

2. content conforms to delegation.claimSchema

3. delegationProof is valid under grantorDID

4. proof is valid under granteeDID (enables ZKP verification)

Does NOT verify:

• VC’s issuer field (can be anyone, including the Holder)

• granteeDID matches VC’s issuer

11.4.3 Holder Re-Packaging

Holders can re-issue received VCs under their own DID:

• VC’s issuer becomes Holder’s DID

• VC’s proof becomes Holder’s signature

• Each claim’s content, delegation, delegationProof, proof remain unchanged

• Verification remains unchanged (still trusts grantorDID)

This enables Holders to maintain privacy from service providers while proving delegated authority through ZKP.

11.5 Verifiable Presentations and ZKP Generation

11.5.1 VP as Internal Structure

Unlike W3C specifications, AMATELUS uses VPs internally only:

• VPs are never submitted directly to issuers or verifiers

• VPs serve to organize claims before ZKP generation

• Holders extract only required claims from multiple VCs and assemble them into a VP

• ZKP is generated from the VP’s selected claims, not the original VCs

11.5.2 ZKP Input Size Reduction

This design dramatically reduces computational cost:

• Traditional method: ZKP includes all claims from all VCs

• VP+Individual Signatures method: ZKP includes only selected claims

• Efficiency gain: If Holder needs 3 claims from 23 total, ZKP input shrinks to \(\approx 1/8\)

• Mobile impact: Battery consumption, memory use, and response time all improve proportionally

Each claim’s individual proof (recipient’s signature) enables this efficiency:

• Allows claims to be verified independently

• Prevents Holder from modifying claim content (signature would fail)

• Enables selective disclosure without revealing unneeded claims

11.5.3 Submission to Issuers

When requesting a new VC from an issuer:

1. Holder creates a VP (internal only) from relevant credentials

2. Holder generates a ZKP with public inputs including:

   • Holder’s DID (issuer needs to record who is requesting)

   • Required fields (e.g., name, age category, income threshold proof)

   • grantorDIDs (proof authorities)

3. Holder submits: {zkp, publicInputs} only

4. Issuer verifies ZKP and creates new VC with credentialSubject.id from public input

11.5.4 Submission to Verifiers

When proving attributes to a service provider:

1. Holder creates a VP (internal only) from relevant credentials

2. Holder generates a ZKP with public inputs including:

   • Required properties only (e.g., age \(\geq \) 20, residence in Japan)

   • Holder’s DID is hidden in ZKP’s secret inputs

   • grantorDIDs (proof authorities)

3. Holder submits: {zkp, publicInputs} only

4. Verifier verifies ZKP without learning:

   • Holder’s identity (DID)

   • Specific personal information (exact birthdate, address, etc.)

   • Which claims or VCs were used

   • Original credential content

This achieves complete privacy for cross-service authentication: the verifier learns only what is cryptographically necessary.

11.6 Security Properties

11.6.1 Depth Limitation Proofs

Lean 4 formally proves three key properties:

1. Termination: verifyChain always completes in finite time (via termination_by remainingDepth)

2. Finite Chain Length: No valid chain can exceed initialMaxDepth

3. N-Layer Finiteness: Multi-layer delegations remain bounded

11.6.2 Circular Delegation Prevention

DIDs in a chain must be unique (O(n) check):

• Detects cycles by comparing getAllDIDs(chain) with getAllDIDs(chain).eraseDups

• verifyChain returns false if duplicates found

11.6.3 Holder-Centric Verification

By focusing verification on grantorDID rather than issuer:

• Issuer Independence: Credentials can be re-issued by different parties without verification failure

• Holder Privacy: Holders can re-package credentials under their own DID without disclosure

• ZKP Compatibility: Delegation authority persists even when issuer is hidden via ZKP

11.6.4 Per-Claim Signature Guarantees

Each claim’s proof (recipient’s signature):

• Prevents Holders from modifying claim content

• Enables independent claim verification (critical for VP-based ZKP generation)

• Survives Holder re-packaging (signature remains unchanged)

11.7 Examples

11.7.1 Single-Layer Delegation

Government delegates “Resident Certificate” authority to municipalities:

Government (grantorDID)
  v Delegation Credential
    (grants Resident Certificate authority)
    maxDepth = 1
  v
Municipality (granteeDID)
  v Attribute Credential
    (issues resident data with embedded delegation)
  v
Resident (Holder)
  v Requests Bank Account
    (verifier: Bank)
  v
Bank
  - Verifies ZKP
  - Confirms government DID in trustedAnchors
  - Approves account

11.7.2 Multi-Layer Delegation with Holder Privacy

Government (grantorDID, maxDepth=3)
  v Prefecture (maxDepth=2)
  v Municipality (maxDepth=1)
  v Resident (Holder, issues self-signed VC)
  v Applies for Job
    (submits ZKP: age >= 18, no criminal record)
  v
Employer (Verifier)
  - Verifies ZKP
  - Does NOT learn:
    - Resident's identity
    - Exact age/birthdate
    - Criminal history status
    - Original credentials
  - Learns only:
    - Age threshold met
    - Background check passed
    - Government issued proof