# Eldersafe Identity Revelation Protocol v1

## Purpose

To define the cryptographic, procedural, and contractual mechanism by which a pseudonymous Eldersafe identity (member_number → BSV public key) may be linked to a real human identity — and to guarantee that this linkage is impossible except through a Danish court order acknowledged by both Eldersafe and Ældre Sagen, verified by an independent notary, and permanently recorded.

---

## Parties

| Party | Role |
|-------|------|
| **Danish Court** | Issues digitally signed court order; sole authority that can initiate revelation |
| **Eldersafe** | Holds Shamir shard A of identity decryption key; acknowledges court order on-chain |
| **Ældre Sagen** | Holds Shamir shard B of identity decryption key; acknowledges court order on-chain |
| **Notary** | Trusted third party; air-gapped HSM holding Shamir shard C PLUS sole ability to decrypt court order; verifies authenticity before releasing shard C |
| **Requesting Authority** | Police, emergency services, or legal guardian — the party that petitions the court and presents the order |

---

## Cryptographic Primitives

### Layer 1: Identity Map Encryption

The mapping `member_number → real_identity` is encrypted with a symmetric key K.

K is split via **Shamir Secret Sharing (3-of-3)**. All three shards are required to reconstruct K.

| Shard | Holder | Storage |
|-------|--------|---------|
| Shard A | Eldersafe | Eldersafe infrastructure (encrypted at rest) |
| Shard B | Ældre Sagen | Ældre Sagen infrastructure (encrypted at rest) |
| Shard C | Notary | Air-gapped HSM; never leaves HSM in unencrypted form |

No party can decrypt the identity map alone. Any two parties cannot decrypt it. Only all three together can.

### Layer 2: Court Order Encryption

The full text of the court order is encrypted to the **notary's public key**.

Only the notary can decrypt the court order. Not Eldersafe. Not Ældre Sagen. Not the court (the court issues the order but does not hold the notary's private key).

This is **not a shard** — it is a complete, notary-exclusive encryption. The notary alone reads the order.

---

## Smart Contract States

The BSV smart contract governs the process as a state machine. Only the `court_order_hash` is recorded on-chain — never the member number.

```
  ┌─────────┐
  │ DORMANT │  ← normal state; no revelation in progress
  └────┬────┘
       │ court order hash submitted on-chain
       ▼
  ┌─────────────────┐
  │ COURT_PRESENTED │  ← order hash recorded; awaiting party acknowledgements
  └────┬───┬────────┘
       │   │
       │   │ Eldersafe acknowledges (signed on-chain)
       │   ▼
       │  ┌──────────────┐
       │  │ ELDERSAFE_ACK │
       │  └──────┬───────┘
       │         │ Ældre Sagen acknowledges (signed on-chain)
       │         ▼
       │  ┌────────────────┐
       │  │ AELDRESAGEN_ACK │  ← both parties have acknowledged
       │  └───────┬────────┘
       │          │
       ▼          ▼
  ┌──────────────────┐
  │  SETTLED          │  ← final state; notary has acted
  │  └─ outcome:      │
  │     RELEASE or    │
  │     REFUSE        │
  └───────────────────┘
```

On-chain data per state transition:

| Transition | Data written |
|------------|-------------|
| DORMANT → COURT_PRESENTED | `court_order_hash`, `timestamp` |
| COURT_PRESENTED → ELDERSAFE_ACK | `eldersafe_signature`, `timestamp` |
| ELDERSAFE_ACK → AELDRESAGEN_ACK | `aeldresagen_signature`, `timestamp` |
| AELDRESAGEN_ACK → SETTLED | `outcome` (RELEASE or REFUSE), `notary_signature`, `timestamp` |

---

## Protocol Flow

### Step 1: Court Issues Order

Danish court digitally signs a court order containing:

- `member_number(s)` requested
- `legal_basis` (statute reference, case ID)
- `court_signature`
- `expiry` (orders are time-bound)

The requesting authority receives the signed order.

### Step 2: Order Served to Parties

Requesting authority serves the court order to both Eldersafe and Ældre Sagen through standard legal service channels.

Both parties now know: *a court order exists for member number(s) X, with hash H.*

### Step 3: On-Chain + Notary Submission

Requesting authority submits:

**On-chain:** `court_order_hash` → smart contract enters `COURT_PRESENTED`

**Off-chain to notary:** `Encrypt(court_order_full, notary_public_key)` — the complete, signed court order, encrypted so only the notary can decrypt it

### Step 4: Eldersafe Acknowledges

Eldersafe verifies they have been served an order matching hash H. They sign a transaction on-chain: "I acknowledge court order with hash H."

Contract enters `ELDERSAFE_ACK`.

### Step 5: Ældre Sagen Acknowledges

Ældre Sagen verifies they have been served an order matching hash H. They sign a transaction on-chain: "I acknowledge court order with hash H."

Contract enters `AELDRESAGEN_ACK`.

### Step 6: Smart Contract Emits Event

Both acknowledgements recorded on-chain → contract enters `SETTLED` → emits event:

```
{outcome: RELEASE, court_order_hash: H, timestamp: T}
```

### Step 7: Notary HSM Verifies and Acts

The notary's HSM watches the BSV chain for SETTLED events on the Eldersafe identity revelation contract.

When it detects one, the HSM:

1. **Decrypts** the court order using notary's private key
2. **Verifies** `hash(court_order_full) == on_chain_hash`
3. **Verifies** `court_signature` against registered Danish court public keys
4. **Verifies** the court order has not expired

If all checks pass:
- Releases Shamir shard C to a pre-designated secure channel
- Signs on-chain: `{outcome: RELEASE, notary_signature, timestamp}`

If any check fails:
- Does NOT release shard C
- Signs on-chain: `{outcome: REFUSE, notary_signature, timestamp, reason_code}`

---

## Notary HSM Verification Logic

```
function process_settled(court_order_hash):

    // 1. Decrypt court order
    court_order = decrypt(encrypted_order, notary_private_key)

    // 2. Hash match
    if hash(court_order) != court_order_hash:
        refuse("HASH_MISMATCH")

    // 3. Signature verification
    signer = verify_signature(court_order, court_order.court_signature)
    if signer not in REGISTERED_COURT_KEYS:
        refuse("INVALID_COURT_SIGNATURE")

    // 4. Expiry check
    if court_order.expiry < now():
        refuse("ORDER_EXPIRED")

    // 5. All checks passed
    release(shard_c, secure_channel)
    record_on_chain(RELEASE, notary_signature, timestamp)
```

---

## Audit Trail

| Record | Location | Contains | Permanence |
|--------|----------|----------|------------|
| State transitions | BSV blockchain | `court_order_hash`, acknowledgements, outcome | Permanent, immutable |
| Court order full text | Notary off-chain log | Decrypted order, verification results, release decision | Deletable (functional erasure) |
| Member number | **Never on-chain** | — | — |

The on-chain record is pseudonymous — it shows a revelation occurred under a specific hash, but does not reveal *whose* identity. The notary's log ties hash to member number and is off-chain, deletable infrastructure.

---

## Functional Erasure (GDPR Article 17)

Erasure of any single element renders the identity map permanently inaccessible:

| Destroy | Effect |
|---------|--------|
| Shard A (Eldersafe) | K cannot be reconstructed; identity map is anonymous |
| Shard B (Ældre Sagen) | Same |
| Shard C (Notary HSM) | Same |
| Notary off-chain logs | Hash can no longer be linked to member number; on-chain record remains but points to nobody |

The on-chain record persists — but without any shard or log, it is cryptographically impossible to link it to a human identity.

---

## Edge Cases

### Notary Refusal

If the HSM refuses (hash mismatch, invalid signature, expired order), the REJECT outcome is recorded on-chain. This is a public, timestamped record that the process was attempted and failed.

The requesting authority may:
- Correct the error (reissue order, re-encrypt correctly) and retry
- Petition the court to compel the notary (new court order)
- If notary is uncooperative or compromised: replace notary (new key ceremony required; old shard C becomes useless → privacy preserved)

### Party Non-Compliance

If Eldersafe or Ældre Sagen fails to acknowledge on-chain, the contract remains in `COURT_PRESENTED` or `ELDERSAFE_ACK` indefinitely. The court may compel the non-compliant party. Both are Danish organizations subject to Danish jurisdiction.

### Lost or Destroyed Shard

If any shard is lost or destroyed, the identity map is permanently inaccessible. This is a feature, not a bug — it enforces the principle that identity revelation is break-glass-only and never casual.

### Key Ceremony (Initial Setup)

The initial generation of K and distribution of shards A, B, C must occur in a witnessed key ceremony with representatives from all three shard-holding parties present. All three parties must attest on-chain to receipt of their shard before any member identities are encrypted. The ceremony is a prerequisite for the protocol to be considered operational.

---

## Summary

```
COURT ORDER ──→ Served to Eldersafe + Ældre Sagen
                Encrypted copy → Notary (notary-exclusive)

ON-CHAIN ────→ State machine: COURT_PRESENTED → ELDERSAFE_ACK → AELDRESAGEN_ACK → SETTLED
               Only court_order_hash on-chain. Never member_number.

NOTARY HSM ──→ Decrypts order → verifies hash → verifies court signature → releases shard C
               Two independent verifications (order authenticity + party acknowledgements)

IDENTITY ────→ Shamir 3-of-3: shards A+B+C reconstruct K → decrypt(member_number → identity)
MAP             Only possible after all seven protocol steps complete.
```