# WIA-LEG-006: Digital Asset Inheritance Standard
## Version 1.0 - Phase 1: Data Format Specification

**Status:** Final
**Published:** 2025-01-15
**Authors:** WIA Technical Committee on Digital Legacy
**License:** MIT License

---

## 1. Introduction

### 1.1 Purpose
This specification defines the data format for digital asset inheritance plans, enabling interoperable estate planning across wallets, platforms, and legal systems.

### 1.2 Scope
Phase 1 covers:
- JSON schema for inheritance plans
- Asset inventory structures
- Beneficiary definitions
- Distribution rules
- Trigger mechanisms
- Metadata and versioning

### 1.3 Philosophy
Embodies 弘益人間 (Hongik Ingan) - "Benefit All Humanity" through universal accessibility and legal compliance.

---

## 2. Data Model Overview

### 2.1 Core Structure
```json
{
  "wiaStandard": "LEG-006",
  "version": "1.0",
  "inheritancePlan": {
    "planId": "string (UUID v4)",
    "metadata": {},
    "owner": {},
    "assets": [],
    "beneficiaries": [],
    "distribution": {},
    "triggers": [],
    "legal": {},
    "execution": {}
  },
  "signatures": []
}
```

### 2.2 Field Definitions

#### 2.2.1 Metadata
```json
"metadata": {
  "created": "ISO 8601 timestamp",
  "lastModified": "ISO 8601 timestamp",
  "version": "Semantic version (e.g., 1.2.3)",
  "previousVersionHash": "SHA-256 hash of previous version",
  "title": "Human-readable plan name",
  "description": "Plan description",
  "jurisdiction": "ISO 3166-2 code",
  "language": "IETF BCP 47 language tag",
  "currency": "ISO 4217 currency code",
  "tags": ["array of strings"],
  "confidentiality": "public|private|confidential",
  "encryption": {
    "algorithm": "AES-256-GCM|RSA-4096",
    "keyDerivation": "PBKDF2-HMAC-SHA256|Argon2id",
    "encryptedFields": ["array of JSON paths"]
  }
}
```

---

## 3. Asset Specifications

### 3.1 Cryptocurrency Assets
```json
{
  "assetId": "unique identifier",
  "type": "cryptocurrency",
  "classification": "primary-holding|savings|investment|trading",
  "cryptocurrency": {
    "symbol": "BTC|ETH|etc",
    "fullName": "Bitcoin|Ethereum|etc",
    "network": "mainnet|testnet",
    "amount": "string (decimal)",
    "walletType": "hardware|software|paper|custodial",
    "walletProvider": "string",
    "addresses": [
      {
        "address": "blockchain address",
        "type": "P2PKH|P2WPKH|etc",
        "balance": "string (decimal)",
        "derivationPath": "BIP32/BIP44 path"
      }
    ]
  },
  "access": {
    "method": "single-sig|multi-sig|shamir-secret",
    "requiredSignatures": "number (for multi-sig)",
    "totalKeys": "number (for multi-sig)",
    "keyShares": []
  },
  "valuation": {
    "acquisitionCost": {"amount": number, "currency": "string", "date": "ISO 8601"},
    "currentValue": {"amount": number, "currency": "string", "asOf": "ISO 8601"},
    "taxBasis": "FIFO|LIFO|HIFO|specific-identification"
  }
}
```

### 3.2 NFT Assets
```json
{
  "assetId": "unique identifier",
  "type": "nft",
  "classification": "art|collectible|gaming|utility|domain",
  "nft": {
    "blockchain": "Ethereum|Polygon|Solana|etc",
    "standard": "ERC-721|ERC-1155|SPL|etc",
    "contractAddress": "smart contract address",
    "tokenId": "token identifier",
    "ownerAddress": "current owner address",
    "metadata": {
      "name": "NFT name",
      "description": "NFT description",
      "image": "IPFS or HTTP URL",
      "attributes": [],
      "externalUrl": "optional external URL"
    },
    "provenance": []
  },
  "rights": {
    "copyright": "retained|transferred|shared",
    "commercialUse": "permitted|restricted|prohibited",
    "transferable": boolean,
    "royalties": {"percentage": number, "recipient": "address"}
  }
}
```

### 3.3 Digital Real Estate
```json
{
  "assetId": "unique identifier",
  "type": "digital-real-estate",
  "classification": "investment|business|personal",
  "metaverseProperty": {
    "platform": "Decentraland|The Sandbox|etc",
    "parcels": [
      {"coordinates": {}, "size": "string", "landId": "token ID"}
    ],
    "blockchain": "Ethereum|Polygon|etc",
    "contractAddress": "smart contract address",
    "tokenIds": ["array of token IDs"],
    "developments": []
  },
  "access": {
    "platformAccount": {
      "username": "string",
      "email": "string",
      "wallet": "connected wallet address"
    }
  }
}
```

---

## 4. Beneficiary Framework

### 4.1 Individual Beneficiary
```json
{
  "beneficiaryId": "unique identifier",
  "identity": {
    "did": "W3C Decentralized Identifier",
    "legalName": "full legal name",
    "relationship": "spouse|child|sibling|parent|friend|charity",
    "dateOfBirth": "ISO 8601 date",
    "contact": {
      "email": "email address",
      "phone": "E.164 format",
      "address": {}
    }
  },
  "allocation": {
    "percentage": "number 0-100",
    "specificAssets": ["array of assetIds"],
    "residualShare": "percentage of residual estate"
  },
  "conditions": {
    "ageRequirement": "minimum age",
    "educationMilestone": "description",
    "trustStructure": {
      "type": "spendthrift|discretionary|special-needs",
      "trustee": "DID of trustee",
      "distributionSchedule": []
    }
  },
  "contingent": {
    "primary": boolean,
    "alternates": ["beneficiaryIds"],
    "failureConditions": ["predeceased|disclaimed|incapacitated"]
  }
}
```

### 4.2 Organizational Beneficiary
```json
{
  "beneficiaryId": "unique identifier",
  "identity": {
    "type": "charitable-organization|trust|foundation|corporation",
    "legalName": "official registered name",
    "taxId": "EIN or equivalent",
    "charityRegistration": "501(c)(3) or equivalent",
    "wallet": "receiving address"
  },
  "allocation": {
    "percentage": "number 0-100",
    "specificAssets": [],
    "residualShare": "percentage"
  },
  "purpose": "description of charitable purpose"
}
```

---

## 5. Distribution Logic

### 5.1 Distribution Methods
- `equal`: Equal distribution among beneficiaries
- `percentage`: Custom percentage allocation
- `specific-bequest`: Specific assets to specific beneficiaries
- `residual`: Remainder after specific bequests
- `conditional`: Based on conditions being met

### 5.2 Distribution Rules Schema
```json
"distribution": {
  "method": "equal|percentage|mixed",
  "rules": [
    {
      "ruleId": "unique identifier",
      "type": "specific-bequest|percentage-split|residual",
      "asset": "assetId or pattern",
      "beneficiary": "beneficiaryId",
      "condition": "optional condition expression"
    }
  ],
  "simultaneousDeath": {
    "presumption": "beneficiary-predeceased|uniform-simultaneous-death-act",
    "survivorshipPeriod": "duration (e.g., 30 days)"
  },
  "taxOptimization": {
    "strategy": "marital-deduction|charitable-remainder|generation-skipping",
    "estateTaxExemption": number,
    "jurisdiction": "tax jurisdiction"
  }
}
```

---

## 6. Trigger Mechanisms

### 6.1 Trigger Types

#### 6.1.1 Dead Man's Switch
```json
{
  "triggerId": "unique identifier",
  "type": "dead-mans-switch",
  "inactivityPeriod": "number (days)",
  "unit": "days|hours|months",
  "checkInMethod": "biometric-app|email|sms|multi-factor",
  "notificationSchedule": [
    {
      "beforeTrigger": "days before trigger",
      "recipients": ["owner|executor|beneficiary"],
      "method": "email|sms|push|certified-mail"
    }
  ],
  "gracePeriod": "days after initial trigger",
  "resetOnActivity": boolean
}
```

#### 6.1.2 Oracle-Verified Trigger
```json
{
  "triggerId": "unique identifier",
  "type": "oracle-verified",
  "oracle": {
    "type": "death-certificate|court-order|medical-incapacity",
    "provider": "oracle service name",
    "apiEndpoint": "HTTPS URL",
    "requiredConfirmations": "number of oracle confirmations needed",
    "verificationMethod": "multi-jurisdiction-consensus|single-authority"
  }
}
```

#### 6.1.3 Manual Executor Trigger
```json
{
  "triggerId": "unique identifier",
  "type": "manual-executor",
  "authorizedParties": ["array of DIDs"],
  "requiredSignatures": "number of signatures needed",
  "signatories": ["executor|attorney|beneficiary"],
  "documentationRequired": ["death-certificate|letters-testamentary|court-order"]
}
```

### 6.2 Trigger Logic
```json
"triggerLogic": {
  "operator": "OR|AND",
  "minimumConfidence": "0.0-1.0 (e.g., 0.95)",
  "disputeResolution": {
    "arbitrator": "arbitration service",
    "appealPeriod": "days"
  }
}
```

---

## 7. Legal Compliance

### 7.1 Jurisdiction Support
- ISO 3166-2 jurisdiction codes
- Support for multiple concurrent jurisdictions
- Conflict-of-law rules specification

### 7.2 Required Legal Fields
```json
"legal": {
  "governingLaw": "ISO 3166-2 code",
  "testamentaryCapacity": {
    "certifiedBy": "attorney|physician",
    "date": "ISO 8601",
    "documentHash": "SHA-256 hash"
  },
  "witnesses": [
    {
      "name": "witness name",
      "signature": "digital signature",
      "timestamp": "ISO 8601"
    }
  ],
  "noContest": boolean,
  "arbitration": {
    "required": boolean,
    "forum": "arbitration service",
    "rules": "AAA|JAMS|ICC"
  }
}
```

---

## 8. Validation Rules

### 8.1 Required Fields
- `wiaStandard`: Must be "LEG-006"
- `version`: Must be "1.0"
- `inheritancePlan.planId`: Must be UUID v4
- `inheritancePlan.metadata.created`: Must be valid ISO 8601
- `inheritancePlan.owner.identity.did`: Must be valid DID

### 8.2 Constraints
- Total beneficiary allocation must equal 100% or less
- Asset IDs must be unique within plan
- Beneficiary IDs must be unique within plan
- Dates must not be in the future (except for scheduled events)

### 8.3 Cross-Field Validation
- Distribution rules must reference existing assets and beneficiaries
- Trigger signatories must be defined parties
- Conditional beneficiaries must have valid conditions

---

## 9. Security Considerations

### 9.1 Encryption
- All private keys and seed phrases MUST be encrypted
- Recommended: AES-256-GCM or RSA-4096
- Key derivation: PBKDF2-HMAC-SHA256 with 100,000+ iterations

### 9.2 Access Control
- Separate encryption for different data sensitivity levels
- Owner-only access: Private keys, seed phrases
- Executor access: Asset locations, beneficiary contacts
- Beneficiary access: Allocation information only

### 9.3 Audit Trail
- Every plan modification MUST include previousVersionHash
- Timestamps MUST be immutable
- Digital signatures MUST be verifiable

---

## 10. Examples

### 10.1 Minimal Valid Plan
See repository: `examples/minimal-plan.json`

### 10.2 Comprehensive Plan
See repository: `examples/comprehensive-plan.json`

### 10.3 Multi-Beneficiary Plan
See repository: `examples/multi-beneficiary-plan.json`

---

## 11. Interoperability

### 11.1 JSON-LD Context
Available at: `https://wiastandards.com/contexts/leg-006/v1.0`

### 11.2 API Endpoints
See Phase 2 specification (v1.1) for API details.

### 11.3 Smart Contract Integration
See Phase 3 specification (v1.2) for on-chain integration.

---

## 12. References

- W3C Decentralized Identifiers: https://www.w3.org/TR/did-core/
- ISO 8601 Date/Time: https://www.iso.org/iso-8601-date-and-time-format.html
- ISO 3166-2 Jurisdiction Codes: https://www.iso.org/iso-3166-country-codes.html
- BIP32 Hierarchical Deterministic Wallets: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
- ERC-721 Non-Fungible Token Standard: https://eips.ethereum.org/EIPS/eip-721

---

## Appendix A: JSON Schema

Complete JSON Schema available at:
`https://wiastandards.com/schemas/leg-006/v1.0/inheritance-plan.json`

---

**弘益人間 · Benefit All Humanity**

© 2025 World Certification Industry Association
Licensed under MIT License