1
Nomenclature and Scope
▶
1.1
Terminology
▶
1.1.1
AMT Protocol (Technical Name)
1.1.2
AMATELUS (Marketing Name)
1.1.3
Relationship
1.2
Document Scope
2
Introduction
▶
2.1
AMATELUS Protocol Overview
▶
2.1.1
What AMATELUS Provides
2.1.2
What AMATELUS Does NOT Provide
2.1.3
Design Philosophy
2.2
Scope of Formal Verification
3
did:amt Method Specification
▶
3.1
Abstract
3.2
did:amt Syntax
▶
3.2.1
Crockford’s Base32 Character Set
3.3
CRUD Operations
▶
3.3.1
Create: Local Generation
3.3.2
Version 0 Pre-DID Template
3.3.3
Read: Local Resolution
3.3.4
Update: Not Supported
3.3.5
Deactivate: Key Destruction
3.4
Cryptographic Properties
▶
3.4.1
DID Identifier Security
3.4.2
DID Ownership Proof
3.4.3
Privacy
3.4.4
Operational Robustness
3.5
Future Evolution: PQC Transition
▶
3.5.1
Versioning for Cryptographic Agility
3.5.2
Foreseeable Changes (AMT v1+)
3.5.3
Reproducible Version 0 Example
3.6
Version 1: Explicit DIDComm Key Agreement Profile
▶
DIDComm processing.
Reproducible two-key vector.
4
Deployment Models
▶
4.1
Service-Driven Model (Primary)
4.2
Physical Proximity Model (Supplementary)
5
Technical Specifications
▶
5.1
DID Document Design Principles
▶
5.1.1
Critical Design Decision: Abolition of serviceEndpoint
5.2
DIDComm Integration
▶
5.2.1
Message Structure
5.2.2
Security Properties
5.3
Verifiable Credentials
▶
5.3.1
VC Structure
5.3.2
Delinkage Information
5.4
Zero-Knowledge Proofs
▶
5.4.1
Security Guarantees
5.4.2
Session Freshness Profiles
5.4.3
Computational Efficiency
6
Trust Architecture
▶
6.1
Responsibility Boundaries
6.2
Trust Origin
6.3
Bounded Delegation Profiles
7
Cryptographic Foundations
▶
7.1
Security Assumptions
7.2
Threat Model and Mitigations
▶
7.2.1
Impersonation Attack (Different Secret Key)
7.2.2
Replay Attack (Same ZKP, Same User)
7.2.3
Man-in-the-Middle Attack
7.2.4
Sybil Attack (Multiple DIDs)
8
Privacy Architecture
▶
8.1
Anti-Linkability Across Services
8.2
Zero-Knowledge Property
▶
8.2.1
Privacy Preservation Under DIDComm
8.2.2
Application-Layer Privacy Considerations
8.3
Deniable Authentication
9
Implementation Guidance
▶
9.1
Wallet Implementation Requirements
▶
9.1.1
Secret Key Management
9.1.2
DID Lifecycle
9.1.3
VC Storage
9.2
Service Provider Integration
▶
9.2.1
DIDComm Endpoint Setup
9.2.2
Authorization Decision Points
9.2.3
Challenge Management by Presentation Profile
9.3
Deployment Scenarios
▶
9.3.1
One-Time Verification (Age Confirmation)
9.3.2
Service Registration (Account Opening)
9.3.3
Continuous Authentication (SNS, Messaging)
10
Formally Verifiable JSON Schema Subset
▶
10.1
Abstract
10.2
Design Principles
10.3
Formalization Strategy
▶
10.3.1
Why a Subset?
10.3.2
Lean Formalization Structure
10.3.3
Termination Guarantee
10.4
Supported Features
▶
10.4.1
Type System
10.4.2
String Validation
10.4.3
Numeric Validation
10.4.4
Array Validation
10.4.5
Object Validation
10.4.6
Generic Validation
10.4.7
Schema Composition (Depth-Limited)
10.4.8
Annotation Keywords
10.5
Excluded Features
▶
10.5.1
Reference Keywords
10.5.2
Dynamic Property Validation
10.5.3
Other Excluded Keywords
10.6
Conformance Requirements
▶
10.6.1
Conformant Schema
10.6.2
Conformant Validator
10.7
Future Evolution: Convergence Toward Full JSON Schema
▶
10.7.1
Current Status
10.7.2
Formalization-Driven Expansion
10.7.3
Backward Compatibility
10.7.4
Versioning Strategy
10.8
Example: AMATELUS-Conformant VC Schema
▶
10.8.1
Why This Schema is Conformant
10.9
Security and Robustness
▶
10.9.1
Validation Guarantees
10.9.2
Regular Expression Safety
10.9.3
Schema Complexity Limits
10.10
Authority Is Separate from Schema Conformance
10.11
Mandatory Local Resource Profiles
11
Trust Chain Architecture
▶
11.1
Overview
11.2
Trust Chain Components
▶
11.2.1
Architecture
11.2.2
Critical Design Principles
11.3
Delegation Credentials
▶
11.3.1
Structure
11.3.2
Dynamic Depth Limitation
11.4
Attribute Credentials with Embedded Delegation
▶
11.4.1
Direct Issuance (0-Layer)
11.4.2
Delegated Issuance (1-Layer and Beyond)
11.4.3
Holder Re-Packaging
11.5
Verifiable Presentations and ZKP Generation
▶
11.5.1
VP as Internal Structure
11.5.2
ZKP Input Size Reduction
11.5.3
Submission to Issuers
11.5.4
Submission to Verifiers
11.6
Security Properties
▶
11.6.1
Depth Limitation Proofs
11.6.2
Circular Delegation Prevention
11.6.3
Holder-Centric Verification
11.6.4
Per-Claim Signature Guarantees
11.7
Examples
▶
11.7.1
Single-Layer Delegation
11.7.2
Multi-Layer Delegation with Holder Privacy
11.8
Original Conditions Survive Repackaging
11.9
Authorization Verification
12
Multi-Device Support
▶
12.1
Overview
▶
12.1.1
Background
12.1.2
Design Principles
12.2
Design Philosophy
▶
12.2.1
Comparison with Trust Chain
12.2.2
Claim Transfer Paths
12.2.3
Claim Structure
12.2.4
Transferred Claim Structure
12.2.5
W3C Standard Alignment
12.3
Use Cases
▶
12.3.1
Municipal Certificate Reception
12.3.2
Claim Transfer to Home PC
12.3.3
Claim Utilization (ZKP Generation)
12.4
DIDComm Communication Protocol
▶
12.4.1
DIDComm Overview
12.4.2
DIDComm Message Structure
12.4.3
Authentication Flow
12.5
Claim Transfer Mechanism
▶
12.5.1
Transferred Data
12.5.2
Transfer Signature Generation
12.5.3
Receiving Wallet Validation
12.5.4
Receiving Wallet Storage
12.6
ZKP Efficiency
▶
12.6.1
Per-Claim Transfer Advantages
12.6.2
ZKP Generation Process
12.6.3
Computational Cost Comparison
12.6.4
Privacy Enhancement
12.7
Security Considerations
▶
12.7.1
Private Key Non-Sharing
12.7.2
Dual Signature Security
12.7.3
End-to-End Encryption
12.7.4
Device Authentication
12.7.5
Claim Integrity Verification
12.7.6
Man-in-the-Middle (MITM) Attack Mitigation
12.7.7
Privacy Protection
12.7.8
Protocol-Level Guarantee
12.8
Implementation Guidelines
▶
12.8.1
Wallet Implementation Requirements
12.8.2
Transport Layer Options
12.8.3
Error Handling
12.8.4
Testing Strategy
12.9
Future Extensions
▶
12.9.1
Cloud Synchronization
12.9.2
Group Wallet
12.9.3
Conditional Transfer
12.9.4
Trust Chain Integration
12.10
Formal Verification
12.11
Personal Qualifications and Issuer-Approved Transfer
12.12
Transfer Acceptance Boundary
13
Merkle Revocation and Verification Freshness
▶
13.1
Architecture and Responsibility
13.2
Signed Snapshot
13.3
Merkle Tree Construction
▶
13.3.1
Hash Function
13.3.2
Tree Construction Algorithm
13.3.3
Merkle Proof Generation
13.3.4
Merkle Proof Verification
13.4
Circuit and Verification Contract
13.5
Verifier Processing
13.6
Offline and Disaster Operation
13.7
Lean Model and Limits
13.8
Acceptance Criteria
14
Optional Audit Mechanism and Resident Seed Lifecycle
▶
14.1
Scope and Trust Model
14.2
Derivation and Category Scope
14.3
Resident Credential
14.4
Ordinary Reissue, Relocation and Lost Devices
14.5
Exceptional Seed Rotation
14.6
Proof Relation and Service Verification
14.7
Verification Scope and Acceptance Criteria
14.8
Wallet Authorization of Requested Categories
15
Secret Key Lifecycle Management
▶
15.1
Overview
▶
15.1.1
Key Principles
15.1.2
Scenario Classification
15.2
Secret Key Leakage Response Flow
▶
15.2.1
Preconditions
15.2.2
Response Procedure
15.3
Secret Key Loss: Abuse Concern
▶
15.3.1
Scenario
15.3.2
Response
15.4
Secret Key Loss: Trust Inheritance Flow
▶
15.4.1
Preconditions
15.4.2
Case A: Identity Credential Available
15.4.3
Case B: No Identity Credential
15.5
Planned Secret Key Update Flow
▶
15.5.1
Preconditions
15.5.2
Use Cases
15.5.3
Procedure
15.5.4
Multi-Device Scenario
15.6
Death of Holder
▶
15.6.1
Death Is Not Key Destruction
15.7
Guardianship (Capacity Restriction)
▶
15.7.1
Scenario
15.7.2
Guardianship Initiation Flow
15.7.3
Guardian VC Notification to Issuers
15.7.4
Verifier Guardianship Confirmation Flow
15.7.5
Contract Cancellation by Guardian
15.8
Security Considerations
▶
15.8.1
Key Leakage Attacks
15.8.2
Fraudulent DID Migration
15.8.3
Guardian VC Forgery
15.9
Implementation Recommendations
▶
15.9.1
Holder Responsibilities
15.9.2
Issuer Responsibilities
15.9.3
Verifier Responsibilities
15.10
Formal Theorems
▶
15.10.1
Operation Binding and Personal Reissue
15.10.2
Theorem: Recovery Impossibility Without Identity Credential
15.11
Policy Recommendation Summary
▶
15.11.1
Revocation SLA
15.11.2
Identity Verification Standards
15.11.3
Key Design Principles
15.12
Resident VC Recovery and Seed Continuity
15.13
Canonical Key-Operation Requests
16
Conclusion
Dependency graph
AMATELUS Protocol Spec
Frourio, Inc.
1
Nomenclature and Scope
1.1
Terminology
1.1.1
AMT Protocol (Technical Name)
1.1.2
AMATELUS (Marketing Name)
1.1.3
Relationship
1.2
Document Scope
2
Introduction
2.1
AMATELUS Protocol Overview
2.1.1
What AMATELUS Provides
2.1.2
What AMATELUS Does NOT Provide
2.1.3
Design Philosophy
2.2
Scope of Formal Verification
3
did:amt Method Specification
3.1
Abstract
3.2
did:amt Syntax
3.2.1
Crockford’s Base32 Character Set
3.3
CRUD Operations
3.3.1
Create: Local Generation
3.3.2
Version 0 Pre-DID Template
3.3.3
Read: Local Resolution
3.3.4
Update: Not Supported
3.3.5
Deactivate: Key Destruction
3.4
Cryptographic Properties
3.4.1
DID Identifier Security
3.4.2
DID Ownership Proof
3.4.3
Privacy
3.4.4
Operational Robustness
3.5
Future Evolution: PQC Transition
3.5.1
Versioning for Cryptographic Agility
3.5.2
Foreseeable Changes (AMT v1+)
3.5.3
Reproducible Version 0 Example
3.6
Version 1: Explicit DIDComm Key Agreement Profile
DIDComm processing.
Reproducible two-key vector.
4
Deployment Models
4.1
Service-Driven Model (Primary)
4.2
Physical Proximity Model (Supplementary)
5
Technical Specifications
5.1
DID Document Design Principles
5.1.1
Critical Design Decision: Abolition of serviceEndpoint
5.2
DIDComm Integration
5.2.1
Message Structure
5.2.2
Security Properties
5.3
Verifiable Credentials
5.3.1
VC Structure
5.3.2
Delinkage Information
5.4
Zero-Knowledge Proofs
5.4.1
Security Guarantees
5.4.2
Session Freshness Profiles
5.4.3
Computational Efficiency
6
Trust Architecture
6.1
Responsibility Boundaries
6.2
Trust Origin
6.3
Bounded Delegation Profiles
7
Cryptographic Foundations
7.1
Security Assumptions
7.2
Threat Model and Mitigations
7.2.1
Impersonation Attack (Different Secret Key)
7.2.2
Replay Attack (Same ZKP, Same User)
7.2.3
Man-in-the-Middle Attack
7.2.4
Sybil Attack (Multiple DIDs)
8
Privacy Architecture
8.1
Anti-Linkability Across Services
8.2
Zero-Knowledge Property
8.2.1
Privacy Preservation Under DIDComm
8.2.2
Application-Layer Privacy Considerations
8.3
Deniable Authentication
9
Implementation Guidance
9.1
Wallet Implementation Requirements
9.1.1
Secret Key Management
9.1.2
DID Lifecycle
9.1.3
VC Storage
9.2
Service Provider Integration
9.2.1
DIDComm Endpoint Setup
9.2.2
Authorization Decision Points
9.2.3
Challenge Management by Presentation Profile
9.3
Deployment Scenarios
9.3.1
One-Time Verification (Age Confirmation)
9.3.2
Service Registration (Account Opening)
9.3.3
Continuous Authentication (SNS, Messaging)
10
Formally Verifiable JSON Schema Subset
10.1
Abstract
10.2
Design Principles
10.3
Formalization Strategy
10.3.1
Why a Subset?
10.3.2
Lean Formalization Structure
10.3.3
Termination Guarantee
10.4
Supported Features
10.4.1
Type System
10.4.2
String Validation
10.4.3
Numeric Validation
10.4.4
Array Validation
10.4.5
Object Validation
10.4.6
Generic Validation
10.4.7
Schema Composition (Depth-Limited)
10.4.8
Annotation Keywords
10.5
Excluded Features
10.5.1
Reference Keywords
10.5.2
Dynamic Property Validation
10.5.3
Other Excluded Keywords
10.6
Conformance Requirements
10.6.1
Conformant Schema
10.6.2
Conformant Validator
10.7
Future Evolution: Convergence Toward Full JSON Schema
10.7.1
Current Status
10.7.2
Formalization-Driven Expansion
10.7.3
Backward Compatibility
10.7.4
Versioning Strategy
10.8
Example: AMATELUS-Conformant VC Schema
10.8.1
Why This Schema is Conformant
10.9
Security and Robustness
10.9.1
Validation Guarantees
10.9.2
Regular Expression Safety
10.9.3
Schema Complexity Limits
10.10
Authority Is Separate from Schema Conformance
10.11
Mandatory Local Resource Profiles
11
Trust Chain Architecture
11.1
Overview
11.2
Trust Chain Components
11.2.1
Architecture
11.2.2
Critical Design Principles
11.3
Delegation Credentials
11.3.1
Structure
11.3.2
Dynamic Depth Limitation
11.4
Attribute Credentials with Embedded Delegation
11.4.1
Direct Issuance (0-Layer)
11.4.2
Delegated Issuance (1-Layer and Beyond)
11.4.3
Holder Re-Packaging
11.5
Verifiable Presentations and ZKP Generation
11.5.1
VP as Internal Structure
11.5.2
ZKP Input Size Reduction
11.5.3
Submission to Issuers
11.5.4
Submission to Verifiers
11.6
Security Properties
11.6.1
Depth Limitation Proofs
11.6.2
Circular Delegation Prevention
11.6.3
Holder-Centric Verification
11.6.4
Per-Claim Signature Guarantees
11.7
Examples
11.7.1
Single-Layer Delegation
11.7.2
Multi-Layer Delegation with Holder Privacy
11.8
Original Conditions Survive Repackaging
11.9
Authorization Verification
12
Multi-Device Support
12.1
Overview
12.1.1
Background
12.1.2
Design Principles
12.2
Design Philosophy
12.2.1
Comparison with Trust Chain
12.2.2
Claim Transfer Paths
12.2.3
Claim Structure
12.2.4
Transferred Claim Structure
12.2.5
W3C Standard Alignment
12.3
Use Cases
12.3.1
Municipal Certificate Reception
12.3.2
Claim Transfer to Home PC
12.3.3
Claim Utilization (ZKP Generation)
12.4
DIDComm Communication Protocol
12.4.1
DIDComm Overview
12.4.2
DIDComm Message Structure
12.4.3
Authentication Flow
12.5
Claim Transfer Mechanism
12.5.1
Transferred Data
12.5.2
Transfer Signature Generation
12.5.3
Receiving Wallet Validation
12.5.4
Receiving Wallet Storage
12.6
ZKP Efficiency
12.6.1
Per-Claim Transfer Advantages
12.6.2
ZKP Generation Process
12.6.3
Computational Cost Comparison
12.6.4
Privacy Enhancement
12.7
Security Considerations
12.7.1
Private Key Non-Sharing
12.7.2
Dual Signature Security
12.7.3
End-to-End Encryption
12.7.4
Device Authentication
12.7.5
Claim Integrity Verification
12.7.6
Man-in-the-Middle (MITM) Attack Mitigation
12.7.7
Privacy Protection
12.7.8
Protocol-Level Guarantee
12.8
Implementation Guidelines
12.8.1
Wallet Implementation Requirements
12.8.2
Transport Layer Options
12.8.3
Error Handling
12.8.4
Testing Strategy
12.9
Future Extensions
12.9.1
Cloud Synchronization
12.9.2
Group Wallet
12.9.3
Conditional Transfer
12.9.4
Trust Chain Integration
12.10
Formal Verification
12.11
Personal Qualifications and Issuer-Approved Transfer
12.12
Transfer Acceptance Boundary
13
Merkle Revocation and Verification Freshness
13.1
Architecture and Responsibility
13.2
Signed Snapshot
13.3
Merkle Tree Construction
13.3.1
Hash Function
13.3.2
Tree Construction Algorithm
13.3.3
Merkle Proof Generation
13.3.4
Merkle Proof Verification
13.4
Circuit and Verification Contract
13.5
Verifier Processing
13.6
Offline and Disaster Operation
13.7
Lean Model and Limits
13.8
Acceptance Criteria
14
Optional Audit Mechanism and Resident Seed Lifecycle
14.1
Scope and Trust Model
14.2
Derivation and Category Scope
14.3
Resident Credential
14.4
Ordinary Reissue, Relocation and Lost Devices
14.5
Exceptional Seed Rotation
14.6
Proof Relation and Service Verification
14.7
Verification Scope and Acceptance Criteria
14.8
Wallet Authorization of Requested Categories
15
Secret Key Lifecycle Management
15.1
Overview
15.1.1
Key Principles
15.1.2
Scenario Classification
15.2
Secret Key Leakage Response Flow
15.2.1
Preconditions
15.2.2
Response Procedure
15.3
Secret Key Loss: Abuse Concern
15.3.1
Scenario
15.3.2
Response
15.4
Secret Key Loss: Trust Inheritance Flow
15.4.1
Preconditions
15.4.2
Case A: Identity Credential Available
15.4.3
Case B: No Identity Credential
15.5
Planned Secret Key Update Flow
15.5.1
Preconditions
15.5.2
Use Cases
15.5.3
Procedure
15.5.4
Multi-Device Scenario
15.6
Death of Holder
15.6.1
Death Is Not Key Destruction
15.7
Guardianship (Capacity Restriction)
15.7.1
Scenario
15.7.2
Guardianship Initiation Flow
15.7.3
Guardian VC Notification to Issuers
15.7.4
Verifier Guardianship Confirmation Flow
15.7.5
Contract Cancellation by Guardian
15.8
Security Considerations
15.8.1
Key Leakage Attacks
15.8.2
Fraudulent DID Migration
15.8.3
Guardian VC Forgery
15.9
Implementation Recommendations
15.9.1
Holder Responsibilities
15.9.2
Issuer Responsibilities
15.9.3
Verifier Responsibilities
15.10
Formal Theorems
15.10.1
Operation Binding and Personal Reissue
15.10.2
Theorem: Recovery Impossibility Without Identity Credential
15.11
Policy Recommendation Summary
15.11.1
Revocation SLA
15.11.2
Identity Verification Standards
15.11.3
Key Design Principles
15.12
Resident VC Recovery and Seed Continuity
15.13
Canonical Key-Operation Requests
16
Conclusion