12 Multi-Device Support

Definition 24

✓

This chapter covers multi-device support aspects of AMATELUS.

12.1 Overview

The Multi-Device Support specification enables a single Holder to operate wallets with different DIDs on multiple devices and safely transfer claims between devices on a per-claim basis.

12.1.1 Background

Identity-related VCs have the following characteristics:

Local Reception Requirement: Most identity VCs are issued in-person at municipal offices, police stations, etc.
Smartphone Reception: Smartphone is the typical device for in-person VC reception
PC Utilization Need: When participating in the AMATELUS network from home, users typically use a PC

Multi-device support is essential to meet these diverse requirements.

12.1.2 Design Principles

Non-Shared Private Keys: Private keys are never transferred between devices
Per-Claim Transfer: Claims (not entire VCs) are transferred individually
Dual Signatures: Issuer signature + original subject transfer signature
W3C Standard Compliance: Supports holder \(\neq \) credentialSubject
DIDComm Protocol: Uses standard DID-to-DID communication protocol
End-to-End Encryption: Transferred data is always encrypted
Protocol-Level Rules: Claims without signatures are ignored

12.2 Design Philosophy

12.2.1 Comparison with Trust Chain

AMATELUS provides two distinct mechanisms:

Function	Use Case	Mechanism	DID Relationship
Trust Chain	Schema inheritance, authority delegation	DelegationChain	Different organizational DIDs
Multi-Device	Claim sharing	Per-claim transfer	Same Holder’s different DIDs

12.2.2 Claim Transfer Paths

In the AMATELUS protocol, claims are transferred via two paths:

Issuer \(\rightarrow \) Holder_A: Initial claim issuance
Holder_A \(\rightarrow \) Holder_B: Per-claim transfer (subject of this specification)

External submissions always use only ZKPs; claims themselves are never revealed externally.

12.2.3 Claim Structure

All claims must have an issuer signature:

structure SignedClaim where
  content : String
  delegationChain : Option DelegationChain
  issuerSignature : Signature

Protocol-Level Rule: Claims without signatures are ignored.

12.2.4 Transferred Claim Structure

Claims transferred between devices carry dual signatures:

structure TransferredClaim where
  originalClaim : SignedClaim
  originalSubjectDID : ValidDID
  currentHolderDID : ValidDID
  transferProof : Signature
  transferredAt : Nat

Dual Signature Roles:

issuerSignature: Guarantees claim authenticity (issued by municipality)
transferProof: Proves claim ownership and transfer consent (owned and transferred by original DID)

12.2.5 W3C Standard Alignment

W3C VC standards allow holder (VC possessor) and credentialSubject (VC subject) to be different (\(\neq \)).

Per-claim transfer maintains:

Issuer signature remains unchanged (original issuer’s signature)
originalSubjectDID remains unchanged (original DID maintained)
currentHolderDID is the new device’s DID
PC wallet can possess and use for ZKP generation

12.3 Use Cases

12.3.1 Municipal Certificate Reception

Alice brings smartphone to municipal office
Officer verifies smartphone DID: did:amt:alice_smartphone
Municipality issues residence certificate VC to smartphone wallet
Smartphone wallet receives and stores VC

12.3.2 Claim Transfer to Home PC

Alice returns home
PC wallet boots: did:amt:alice_pc
Smartphone wallet initiates claim transfer request to PC wallet
Smartphone wallet generates transfer signature (signed with DID_A private key)
DIDComm protocol encrypts and transfers claim
PC wallet receives, verifies, and stores claim
PC can now participate in AMATELUS network

12.3.3 Claim Utilization (ZKP Generation)

When PC wallet generates ZKP:

{
  "public_inputs": {
    "holder_did": "did:amt:alice_pc",
    "age_gte": 20,
    "residence": "Tokyo"
  },
  "proof": "..."
}

Important Notes:

ZKP generation is performed by PC wallet
originalSubjectDID (smartphone’s original DID) is secret input
currentHolderDID (PC’s DID) is public input
Both issuer and transfer signatures are verified within ZKP
Only required claims are input (other claims are unnecessary)

12.4 DIDComm Communication Protocol

12.4.1 DIDComm Overview

DIDComm (DID Communication) is the standard protocol enabling secure communication between DIDs:

Specification: DIDComm Messaging v2.0
Features:
- End-to-end encryption
- Authenticated messaging
- Transport-agnostic (HTTP, WebSocket, Bluetooth, etc.)

12.4.2 DIDComm Message Structure

Claim Transfer Request

{
  "type": "https://amatelus.org/protocols/claim-transfer/2.0/request",
  "id": "uuid-1234-5678",
  "from": "did:amt:alice_pc",
  "to": "did:amt:alice_smartphone",
  "created_time": 1673568000,
  "body": {
    "request_type": "filtered_claims",
    "filters": {
      "content_patterns": ["name", "address"],
      "issuer": "did:amt:municipality123"
    }
  }
}

Claim Transfer Response

{
  "type": "https://amatelus.org/protocols/claim-transfer/2.0/response",
  "from": "did:amt:alice_smartphone",
  "to": "did:amt:alice_pc",
  "body": {
    "transferred_claims": [
      {
        "original_claim": {
          "content": "{\"name\": \"Alice\", \"address\": \"Tokyo\"}",
          "issuer_signature": "..."
        },
        "original_subject_did": "did:amt:alice_smartphone",
        "current_holder_did": "did:amt:alice_pc",
        "transfer_proof": "...",
        "transferred_at": 1673568010
      }
    ],
    "success": true
  }
}

12.4.3 Authentication Flow

Device Pairing

Initial pairing of two wallets:

PC displays QR code (DID + temporary token)
Smartphone scans QR code
Smartphone sends DIDComm connection request
PC prompts user for approval
User approves on PC
Both devices add peer DID to trusted list

Mutual Authentication

Communication between paired devices:

Request side signs DIDComm message
Response side verifies signature and checks trusted list
Response side sends encrypted response
Request side decrypts and verifies response

12.5 Claim Transfer Mechanism

12.5.1 Transferred Data

Data sent during claim transfer:

{
  "original_claim": {
    "content": "{\"name\": \"Alice\", \"address\": \"Tokyo\"}",
    "issuer_signature": "..."
  },
  "original_subject_did": "did:amt:alice_smartphone",
  "current_holder_did": "did:amt:alice_pc",
  "transfer_proof": "...",
  "transferred_at": 1673568010
}

Unchanged Elements:

original_claim.content: Claim content
original_claim.issuer_signature: Issuer signature
original_subject_did: Original holder DID (smartphone)

Added Elements:

transfer_proof: Transfer signature by original subject (required)
current_holder_did: Current holder DID (PC)
transferred_at: Transfer timestamp

12.5.2 Transfer Signature Generation

The wallet signs the complete TransferPayload, using prepareClaimTransfer and a real signing backend:

request = {
  payload,
  signature: Sign(subjectSK, transferBytes(payload))
}

The preimage domain is AMT-ClaimTransfer-v1. In order, it includes the version, complete original ClaimConditions, original issuer signature, recipient DID, role, purpose, transfer ID, issue time, expiry time and transfer revocation reference. ClaimConditions includes content, subject, issuer, credential reference, expiry, revocation flag and reference, and delegation references. Every field and nested list is length-framed with the same encoding as key-operation requests. There are no unsigned authorization fields or unsigned timestamps.

12.5.3 Receiving Wallet Validation

PC wallet validates received claim:

def validateClaim
    (tc : TransferredClaim)
    (issuerDID : ValidDID)
    (trustedAnchors : List ValidDID) : Bool :=
  let issuerSigValid := tc.originalClaim.verify issuerDID
  let transferSigValid := tc.verifyTransferProof
  let issuerTrusted := trustedAnchors.contains issuerDID
  issuerSigValid && transferSigValid && issuerTrusted

12.5.4 Receiving Wallet Storage

PC wallet stores received claim in this structure:

{
  "claim_id": "uuid-claim-001",
  "original_claim": {
    "content": "{\"name\": \"Alice\"}",
    "issuer_signature": "..."
  },
  "original_subject_did": "did:amt:alice_smartphone",
  "current_holder_did": "did:amt:alice_pc",
  "transfer_proof": "...",
  "storage_metadata": {
    "received_at": "2025-01-13T12:00:00Z",
    "received_from": "did:amt:alice_smartphone",
    "issuer_did": "did:amt:municipality123"
  }
}

12.6 ZKP Efficiency

12.6.1 Per-Claim Transfer Advantages

Problem with V1.0 (VC-based transfer):

Transferring entire VC requires all claims as ZKP inputs during generation
Unnecessary claims bloat the circuit size
High computational cost with privacy concerns

Advantages of V2.0 (Per-claim transfer):

Only required claims input to ZKP circuit
Circuit size minimized, computational cost reduced
Enhanced privacy (unnecessary claims not handled)
Dual signatures preserve issuance and transfer consent; personal use requires issuer approval

12.6.2 ZKP Generation Process

When PC wallet generates ZKP:

structure ZKPSecretInputsForTransferredClaim where
  claimContent : String
  issuerSignature : Signature
  transferSignature : Signature
  originalSubjectDID : ValidDID

structure ZKPPublicInputsForTransferredClaim where
  currentHolderDID : ValidDID
  publicAttributes : List (String $\times$ String)

ZKP Circuit Verification:

issuerSignature is valid (municipality issued)
transferSignature is valid (DID_A owns and transferred)
originalSubjectDID matches subject in claim (integrity)

12.6.3 Computational Cost Comparison

Method	Input Claims	Circuit Size	Computation Cost
V1.0 (VC transfer)	All claims (5)	Large	High
V2.0 (Per-claim transfer)	Required only (1)	Small	Low

12.6.4 Privacy Enhancement

Per-claim transfer enables:

Excluding unnecessary claims from ZKP circuit
Hiding existence of unnecessary claims
Improved selective disclosure granularity

12.7 Security Considerations

12.7.1 Private Key Non-Sharing

Critical Principle: Private keys are never transferred between devices

Each device maintains independent DID and key pair
Only claim data (issuer signature + transfer signature) is transferred
Private key compromise impact is limited to that device

12.7.2 Dual Signature Security

Dual signatures establish original issuance and transfer consent; they do not establish same-person identity:

issuerSignature:
- Guarantees claim authenticity
- Proves issuance by issuer (municipality)
- Prevents tampering
transferProof:
- Proves claim ownership
- Proves original subject (DID_A) owned it
- Proves transfer consent

Security Theorem:

theorem claim_transfer_preserves_issuer_signature :
  forall (claim : SignedClaim)
    (originalSubjectDID currentHolderDID : ValidDID)
    (timestamp : Nat),
  let tc := prepareClaimTransferEvidenceModel claim originalSubjectDID
               currentHolderDID timestamp
  tc.originalClaim.issuerSignature = claim.issuerSignature

12.7.3 End-to-End Encryption

All claim transfers use DIDComm encryption:

Sender encrypts with recipient’s public key
Transport layer applies additional encryption (optional, e.g., TLS)
Recipient decrypts with own private key

12.7.4 Device Authentication

Pairing-Time Authentication

QR code + temporary token
Explicit user approval
Registration in trusted list

Transfer-Time Authentication

Trusted list verification
DIDComm signature verification
Signed expiry and receiver-owned transfer-ID ledger (idempotent retransmission)

12.7.5 Claim Integrity Verification

Receiving wallet verifies:

def validateClaim
    (tc : TransferredClaim)
    (issuerDID : ValidDID)
    (trustedAnchors : List ValidDID) : Bool :=
  let issuerSigValid := tc.originalClaim.verify issuerDID
  let transferSigValid := tc.verifyTransferProof
  let issuerTrusted := trustedAnchors.contains issuerDID
  issuerSigValid && transferSigValid && issuerTrusted

12.7.6 Man-in-the-Middle (MITM) Attack Mitigation

DIDComm protocol provides:

AEAD: Tampering detection
DID Signatures: Sender authenticity guarantee
Pairing Confirmation: User approval
Dual Signatures: Complete integrity guarantee

12.7.7 Privacy Protection

Claim Transfer Secrecy: Transfer fact unknown to third parties
originalSubjectDID Protection: Secret input during ZKP generation
Selective Transfer: Only required claims transferred
Metadata Separation: Transfer history stored locally only

12.7.8 Protocol-Level Guarantee

Claims without signatures are ignored:

All claims must have issuer signature
Transferred claims must have transfer signature
Unsigned claims automatically rejected at protocol level
Tampering attempts automatically fail

12.8 Implementation Guidelines

12.8.1 Wallet Implementation Requirements

Essential Features

DIDComm Support
- Implement DIDComm v2.0 protocol
- Support end-to-end encryption
Device Management
- Manage trusted device list
- Implement pairing (QR code, etc.)
Claim Transfer
- Support claim sending (with filtering)
- Generate transfer signatures (original subject’s private key)
- Support claim receiving (with dual signature verification)
ZKP Generation Extension
- Support currentHolderDID as public input
- Support originalSubjectDID as secret input
- Verify both issuer and transfer signatures in ZKP
- Input only required claims (others unnecessary)
Signature Verification
- Verify issuer signatures
- Verify transfer signatures
- Reject unsigned claims (protocol-level)

Recommended Features

Selective Transfer
- Transfer specific claims only
- Content pattern filtering
- Issuer-based filtering
Transfer History
- Log device and transfer timestamp
- Support transfer revocation (revocation notification)
Automatic Synchronization
- Auto-transfer new claims
- Configure inter-device sync
Claim Management
- Per-claim storage and search
- Display delegation chains
- Claim selection UI for ZKP generation

12.8.2 Transport Layer Options

DIDComm supports multiple transports:

Transport	Use Case	Characteristics
HTTP/HTTPS	Internet via cloud	Cloud relay possible
WebSocket	Real-time communication	Bidirectional
Bluetooth	Local communication	No internet required
NFC	Proximity communication	Very short range

Recommended configuration:

Same network: WebSocket (fast)
Different networks: HTTPS (stable)
Offline: Bluetooth (no internet)

12.8.3 Error Handling

Transfer Failure Response

{
  "type": "https://amatelus.org/protocols/claim-transfer/2.0/error",
  "thid": "uuid-1234-5678",
  "body": {
    "error_code": "SIGNATURE_VERIFICATION_FAILED",
    "error_message": "Signature verification failed",
    "details": {
      "claim_id": "uuid-claim-001",
      "issuer": "did:amt:municipality123"
    }
  }
}

Retry Logic

Detect transfer failure
Retry with exponential backoff (max 3 times)
Notify user on final failure
Log failure

12.8.4 Testing Strategy

Functional Testing

Pairing success/failure
Claim transfer success/failure
Issuer signature verification
Transfer signature verification
Dual signature verification
Filtering functionality
Unsigned claim rejection

Security Testing

MITM attack simulation
Invalid claim rejection
Signature tampering detection
Untrusted device rejection
Automatic unsigned claim rejection

Performance Testing

Large volume claim transfer performance
Encryption/decryption overhead
Network latency handling
ZKP generation time comparison (V1.0 vs V2.0)

ZKP Efficiency Testing

Circuit size comparison by claim count
Performance with required claims only
Comparison with all claims

12.9 Future Extensions

12.9.1 Cloud Synchronization

Use trusted cloud service as relay:

Smartphone -> [Encrypted] -> Cloud -> [Decrypted] -> PC

Requirements:

End-to-end encryption mandatory
Cloud cannot access claim content
Zero-knowledge proof-based backup
Per-claim synchronization

12.9.2 Group Wallet

Safe claim sharing within family or organization:

Parent Wallet <-> Child Wallet (guardian function)
Corporate Wallet <-> Employee Wallet (role proof)

Requirements:

Per-claim sharing control
Dual signatures guarantee integrity
Improved selective disclosure granularity

12.9.3 Conditional Transfer

Enable claim transfer only under specific conditions:

{
  "transfer_policy": {
    "allowed_devices": ["did:amt:alice_pc", "did:amt:alice_tablet"],
    "allowed_time": "09:00-18:00",
    "require_biometric": true,
    "max_transfers": 3,
    "allowed_claims": ["name", "address"]
  }
}

12.9.4 Trust Chain Integration

Combine N-level delegation with per-claim transfer:

Transfer claims containing delegation chains
Verify delegation chains at transfer destination
ZKP efficiency (required claims only)

12.10 Formal Verification

Theorems formally proven in AMATELUS/MultiDevice.lean:

claim_transfer_preserves_issuer_signature
- Issuer signature preserved during transfer
claim_transfer_preserves_content
- Claim content preserved during transfer
transferred_claim_has_transfer_proof
- Transferred claims always have transfer signature
device_trust_symmetric
- Device trust verification symmetry
valid_claim_stays_valid_after_transfer
- Valid claims remain valid after transfer

These theorems establish field preservation and abstract input checks, not physical identity or production-circuit security.

12.11 Personal Qualifications and Issuer-Approved Transfer

Claim copying, pairing and synchronization do not themselves authorize the new key’s controller to claim the original subject’s age or residence. A personal qualification presented under a different DID requires an issuer-approved same-subject relationship. The issuer or an explicitly authorized identity verifier checks the person-to-key relationship under the issuance profile. Two cooperating key controllers cannot establish it by dual signatures alone.

An approval signs its authority, original subject, destination presenter, credential references, purpose, expiry, revocation reference and the role sameSubjectReissue or delegatedPresentation. Verify the authority’s scope and all signed fields. Approval may cover subsequent allowed presentations; ordinary synchronization and presentation need not contact the issuer each time. Proxy presentation must retain the principal’s identity and cannot establish the proxy’s own age, residence or other personal attributes.

The transfer-evidence ZKP helper is a low-level data-consistency model. The authorized proof-generation entry point additionally requires the common bound presentation checks, the approved subject/presenter relation and the matching original claim. Repackaging preserves signed original conditions. Transferring a resident qualification preserves its seed and history; multiple devices do not create multiple independent AHI lineages.

12.12 Transfer Acceptance Boundary

receiveTransferredClaim verifies the original signature and conditions, the complete transfer signature, recipient, role, purpose, expiry, transfer status, and issuer-approved personal relation or scoped delegation. An identical retry is idempotent; reuse of the transfer ID with different content is rejected. The ledger and acceptance effects are committed atomically. Storing a reusable transfer credential does not consume a benefit or vote: those events use their own service transaction state and presentation challenges.

The transferred-presentation check validates the evidence and matches the entire original conditions and signature to the presentation. The proof-generation entry point invokes its cryptographic backend only after this check succeeds. Old tagged examples and synthetic signatures are named EvidenceModel and are not wire verification APIs. Their field-preservation lemmas alone do not establish signature soundness or personal identity.