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
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
Read: Local Resolution
3.3.3
Update: Not Supported
3.3.4
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
Example: Version 0 DID Document
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
Replay Prevention (Application Layer Responsibility)
5.4.3
Computational Efficiency
6
Trust Architecture
▶
6.1
Responsibility Boundaries
6.2
Trust Origin
6.3
One-Layer Trust Limitation
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
Nonce Management (Optional Service Feature)
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
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
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
13
Merkle Tree Revocation
▶
13.1
Abstract
13.2
Background and Motivation
▶
13.2.1
Problem with Bitstring Status List
13.2.2
Design Goals
13.2.3
Personal Issuer Challenge and Solution
13.3
Architecture Overview
▶
13.3.1
Overall Flow
13.3.2
Data Structures
13.4
Merkle Tree Construction
▶
13.4.1
Hash Function
13.4.2
Tree Construction Algorithm
13.4.3
Merkle Proof Generation
13.4.4
Merkle Proof Verification
13.5
ZKP Circuit Integration
▶
13.5.1
Circuit Constraints
13.6
Issuer Operations
▶
13.6.1
VC Issuance
13.6.2
VC Revocation
13.6.3
Periodic Merkle Root Updates
13.7
Holder Operations
▶
13.7.1
ZKP Generation with Revocation
13.8
Verifier Operations
▶
13.8.1
ZKP Verification with Revocation
13.8.2
Offline Verification Mode
13.9
W3C VC Integration
▶
13.9.1
credentialStatus Extension
13.10
Security Analysis
▶
13.10.1
Zero-Knowledge Guarantee
13.10.2
Revocation Safety
13.10.3
Timestamp Forgery Resistance
13.10.4
Replay Attack Resistance
13.11
Computational Complexity
13.12
Implementation Checklist
▶
13.12.1
Issuer Requirements
13.12.2
Holder Requirements
13.12.3
Verifier Requirements
13.13
Conclusion
14
Audit Mechanism: Anonymous Hash Identifier (AHI)
▶
14.1
Overview
▶
14.1.1
Key Premise: AHI is Optional
14.1.2
Problem Statement
14.1.3
Design Goals
14.2
Architecture
▶
14.2.1
Actors and Roles
14.2.2
System Architecture
14.2.3
National ID System Abstraction
14.3
Data Structures
▶
14.3.1
Audit Section Identifier
14.3.2
Anonymous Hash Identifier
14.3.3
National ID Verifiable Credential
14.3.4
Zero-Knowledge Proof for AHI
14.4
Audit Flows
▶
14.4.1
Standard Flow: Without AHI (Privacy-Preserving Mode)
14.4.2
Audit-Required Flow: With AHI
14.4.3
Audit Section ID Generation and Publication
14.4.4
AHI Generation Flow
14.4.5
Fraud Investigation and Audit Flow
14.5
Private Sector Applications
▶
14.5.1
Multi-Account Prevention
14.6
Financial Institution Applications
▶
14.6.1
Account Opening with AHI
14.7
Security Requirements
▶
14.7.1
Hash Function
14.7.2
Zero-Knowledge Proof
14.7.3
Household VC Management
14.7.4
Municipality National ID Management
14.7.5
Audit Section ID Management
14.8
Privacy Protections
▶
14.8.1
Anti-Linkage Across Services
14.8.2
National ID Non-Disclosure
14.8.3
Evasion Prevention
14.9
Legal and Regulatory Requirements
▶
14.9.1
Warrant Issuance Standards
14.9.2
Disclosure Procedure Transparency
14.9.3
Social Consensus Formation
14.10
Implementation Guidelines
▶
14.10.1
Wallet Implementation
14.10.2
Service Provider Implementation
14.10.3
Municipality Implementation
14.11
Formal Verification
▶
14.11.1
Theorem: Anti-Linkability Across Audit Domains
14.11.2
Theorem: Evasion Prevention
14.11.3
Theorem: Privacy Preservation
14.11.4
Cryptographic Security Summary
14.12
Future Research Directions
▶
14.12.1
Technical Challenges
14.12.2
Institutional Challenges
14.12.3
Standardization
Key Design Principles (Audit Mechanism)
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
Key Characteristics
15.6.2
Case A: No Family
15.6.3
Case B: Family Present
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
Theorem: Leakage Recovery Determinism
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
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
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
Read: Local Resolution
3.3.3
Update: Not Supported
3.3.4
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
Example: Version 0 DID Document
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
Replay Prevention (Application Layer Responsibility)
5.4.3
Computational Efficiency
6
Trust Architecture
6.1
Responsibility Boundaries
6.2
Trust Origin
6.3
One-Layer Trust Limitation
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
Nonce Management (Optional Service Feature)
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
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
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
13
Merkle Tree Revocation
13.1
Abstract
13.2
Background and Motivation
13.2.1
Problem with Bitstring Status List
13.2.2
Design Goals
13.2.3
Personal Issuer Challenge and Solution
13.3
Architecture Overview
13.3.1
Overall Flow
13.3.2
Data Structures
13.4
Merkle Tree Construction
13.4.1
Hash Function
13.4.2
Tree Construction Algorithm
13.4.3
Merkle Proof Generation
13.4.4
Merkle Proof Verification
13.5
ZKP Circuit Integration
13.5.1
Circuit Constraints
13.6
Issuer Operations
13.6.1
VC Issuance
13.6.2
VC Revocation
13.6.3
Periodic Merkle Root Updates
13.7
Holder Operations
13.7.1
ZKP Generation with Revocation
13.8
Verifier Operations
13.8.1
ZKP Verification with Revocation
13.8.2
Offline Verification Mode
13.9
W3C VC Integration
13.9.1
credentialStatus Extension
13.10
Security Analysis
13.10.1
Zero-Knowledge Guarantee
13.10.2
Revocation Safety
13.10.3
Timestamp Forgery Resistance
13.10.4
Replay Attack Resistance
13.11
Computational Complexity
13.12
Implementation Checklist
13.12.1
Issuer Requirements
13.12.2
Holder Requirements
13.12.3
Verifier Requirements
13.13
Conclusion
14
Audit Mechanism: Anonymous Hash Identifier (AHI)
14.1
Overview
14.1.1
Key Premise: AHI is Optional
14.1.2
Problem Statement
14.1.3
Design Goals
14.2
Architecture
14.2.1
Actors and Roles
14.2.2
System Architecture
14.2.3
National ID System Abstraction
14.3
Data Structures
14.3.1
Audit Section Identifier
14.3.2
Anonymous Hash Identifier
14.3.3
National ID Verifiable Credential
14.3.4
Zero-Knowledge Proof for AHI
14.4
Audit Flows
14.4.1
Standard Flow: Without AHI (Privacy-Preserving Mode)
14.4.2
Audit-Required Flow: With AHI
14.4.3
Audit Section ID Generation and Publication
14.4.4
AHI Generation Flow
14.4.5
Fraud Investigation and Audit Flow
14.5
Private Sector Applications
14.5.1
Multi-Account Prevention
14.6
Financial Institution Applications
14.6.1
Account Opening with AHI
14.7
Security Requirements
14.7.1
Hash Function
14.7.2
Zero-Knowledge Proof
14.7.3
Household VC Management
14.7.4
Municipality National ID Management
14.7.5
Audit Section ID Management
14.8
Privacy Protections
14.8.1
Anti-Linkage Across Services
14.8.2
National ID Non-Disclosure
14.8.3
Evasion Prevention
14.9
Legal and Regulatory Requirements
14.9.1
Warrant Issuance Standards
14.9.2
Disclosure Procedure Transparency
14.9.3
Social Consensus Formation
14.10
Implementation Guidelines
14.10.1
Wallet Implementation
14.10.2
Service Provider Implementation
14.10.3
Municipality Implementation
14.11
Formal Verification
14.11.1
Theorem: Anti-Linkability Across Audit Domains
14.11.2
Theorem: Evasion Prevention
14.11.3
Theorem: Privacy Preservation
14.11.4
Cryptographic Security Summary
14.12
Future Research Directions
14.12.1
Technical Challenges
14.12.2
Institutional Challenges
14.12.3
Standardization
Key Design Principles (Audit Mechanism)
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
Key Characteristics
15.6.2
Case A: No Family
15.6.3
Case B: Family Present
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
Theorem: Leakage Recovery Determinism
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
16
Conclusion