# J0 — System Planning: Digital Key Management

| Field | Value |
|-------|-------|
| **J-Flow Phase** | J0 — System Planning |
| **Service ID** | 001 |
| **Service Name** | Digital Key Gen2 — Digital Key Management |
| **Source** | services/001-Digital-Key-Gen2-Digital-Key-Management.md (pp. 3–8) |
| **Constitution** | 8 principles (Source-Grounded, Safety-First, Privacy-by-Default, Server-Authoritative, Interface-First, Testability, Explicit, Human-in-the-Loop) |

---

## 1. Functional Requirements

| ID | Requirement | Priority | Source (§) |
|----|-------------|----------|------------|
| FR-001.1 | The system **SHALL** allow an owner to share a digital key with a user/guest by generating configuration data including Owner Key ID, Friend Key ID, expiration date, and restriction function information. | P0 | §4 Detail & Requirements |
| FR-001.2 | The system **SHALL** manage digital keys in owner-key and friend-key units, each identified by a unique Key ID. | P0 | §4 Detail & Requirements |
| FR-001.3 | The system **SHALL** allow owners to manage shared keys (users/guests) directly from their smartphone app. | P0 | §3 Scenario & Process; §4 Business Requirements |
| FR-001.4 | The system **SHALL** enable owners to set expiration dates on shared keys, preventing unintended use beyond the validity period. | P0 | §1 Functional Benefits |
| FR-001.5 | The system **SHALL** enable owners to set usage restriction functions on friend keys at the time of sharing. | P0 | §1 Functional Benefits; §4 Function Image |
| FR-001.6 | The system **SHALL** retain digital key information on the server side, enabling tracking even when the owner or recipient switches devices. | P0 | §4 Detail & Requirements |
| FR-001.7 | The system **SHALL** support key revocation by the owner, rendering a shared key immediately inoperable. | P0 | §2 Solution |
| FR-001.8 | The system **SHALL** maintain an append-only audit log of all key management operations (share, revoke, status changes) to clarify responsibility in case of fraud or accidents. | P1 | §1 Stakeholder Requirements |
| FR-001.9 | The system **SHALL** support key enable/disable control based on subscription and app status, organized as a key issue. | P1 | §4 Detail & Requirements |
| FR-001.10 | The system **SHALL** provide the owner a list view of all registered digital keys (owner keys and friend keys), each linked to validity period and restriction function information. | P1 | §4 Function Image |

---

## 2. Use Cases (from §3 Scenario & Process)

### UC-001.1: Owner Shares Key with User/Guest

**Source**: §3 Use Cases — Case 1

**Process Outline**:
1. Owner opens the Honda smartphone app and navigates to Key Management.
2. Owner selects a vehicle and initiates key sharing.
3. Owner specifies the recipient (user/guest), validity period, and restriction functions.
4. The Key Management Server generates configuration data (Owner Key ID → Friend Key ID mapping, expiration, restrictions).
5. Configuration data is pushed to the recipient's smartphone app via Honda Connected Services.
6. The recipient's app registers the friend key; the recipient can now access the vehicle.
7. The owner's management screen reflects the new shared key in the key list.

### UC-001.2: Owner Manages Shared Keys on Smartphone

**Source**: §3 Use Cases — Case 2

**Process Outline**:
1. Owner opens the Honda smartphone app to the Key Management screen.
2. Owner views the list of all registered digital keys (owner keys + friend keys) with status, validity period, and restriction details.
3. Owner selects a friend key to modify: extend/shorten validity, adjust restriction functions, or revoke.
4. Changes are transmitted to the Key Management Server.
5. Server updates the key record and, if the key is active, pushes the updated configuration to the recipient's device and vehicle telematics.
6. The management screen refreshes to reflect the updated state.

### UC-001.3: Owner Revokes a Shared Key

**Source**: §2 Solution

**Process Outline**:
1. Owner opens the Honda smartphone app and navigates to Key Management.
2. Owner selects an active friend key and chooses "Revoke."
3. App confirms the irreversible action; owner confirms.
4. Key Management Server transitions the key state to Revoked.
5. Server pushes revocation to the vehicle telematics gateway, which invalidates the key on the target vehicle.
6. An audit log entry is written with timestamp, owner ID, key ID, and revocation reason.
7. Owner's management screen shows the key as revoked; recipient's app shows the key as no longer usable.

---

## 3. Non-Functional Requirements

### Performance
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-PERF-01 | Key share operation latency (end-to-end, owner app → recipient notification) | SHALL complete within 5 seconds at p95 |
| NFR-PERF-02 | Key revocation propagation to vehicle | SHALL complete within 3 seconds at p95 |
| NFR-PERF-03 | Key list retrieval | SHALL return within 500 ms at p95 |
| NFR-PERF-04 | Concurrent key share operations | SHALL support 100 req/s sustained |

### Security
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-SEC-01 | All API communications | SHALL use TLS 1.3 |
| NFR-SEC-02 | Authentication for all key management operations | SHALL require OAuth 2.0 with proof-of-possession token |
| NFR-SEC-03 | Key configuration data at rest | SHALL be encrypted (AES-256-GCM) |
| NFR-SEC-04 | Cross-owner access prevention | SHALL reject any operation where the authenticated user is not the key owner |

### Availability
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-AVAIL-01 | Key Management Service uptime | SHALL achieve 99.9% availability |
| NFR-AVAIL-02 | Disaster recovery RPO | SHALL be ≤ 5 minutes |
| NFR-AVAIL-03 | Disaster recovery RTO | SHALL be ≤ 30 minutes |

### Privacy
| ID | Requirement | Target |
|----|-------------|--------|
| NFR-PRIV-01 | No persistent PII storage beyond operational necessity | SHALL tag all PII fields; email and user_id SHALL be encrypted at rest |
| NFR-PRIV-02 | Audit log retention for fraud/accident investigation | SHALL retain for 7 years, then purge |
| NFR-PRIV-03 | Data processing | SHALL occur server-side; PII SHALL NOT be cached on the vehicle |

---

## 4. Cross-Reference: FR → Source

| FR | DKM Section | Excerpt |
|----|-------------|---------|
| FR-001.1 | §4 Detail & Requirements | "During key sharing, the management server generates configuration data including Owner Key ID, Friend Key ID, expiration date, and restriction function information" |
| FR-001.2 | §4 Detail & Requirements | "Digital keys are managed in units such as Owner Key/Friend Key, and each key is identified by its Key ID" |
| FR-001.3 | §4 Business Requirements | "Owners can manage users/guests who share key data directly from their smartphones" |
| FR-001.4 | §1 Functional Benefits | "Expiration dates and usage areas can be set, preventing unintended use" |
| FR-001.5 | §1 Functional Benefits | "Expiration dates and usage areas can be set" |
| FR-001.6 | §4 Detail & Requirements | "Digital key-related information is retained on the server side and can be tracked even when switching devices" |
| FR-001.7 | §2 Solution | "Management functions related to digital keys are configured as server-side functions" |
| FR-001.8 | §1 Stakeholder Requirements | "Enhance logs and management to clarify responsibility in case of fraud or accidents" |
| FR-001.9 | §4 Detail & Requirements | "Key enable/disable control based on subscription and app status is organized as a key issue" |
| FR-001.10 | §4 Function Image | "A screen where you can check the list of registered digital keys (owner key/friend key) for the owner" |

---

## 5. Constitution Compliance Check

| # | Principle | Status | Evidence |
|---|-----------|--------|----------|
| 1 | Source-Grounded | PASS | Every FR cites a specific DKM section; no invented requirements |
| 2 | Safety-First | PASS | Revocation disables keys immediately; default state is no-access |
| 3 | Privacy-by-Default | PASS | PII fields tagged; encryption at rest; no vehicle-side PII caching |
| 4 | Server-Authoritative | PASS | Key decisions made server-side; vehicle caches only |
| 5 | Interface-First | PASS | Use cases define actor→system interactions before implementation |
| 6 | Testability | PASS | All FRs use SHALL with measurable NFR targets |
| 7 | Explicit | PASS | No assumed defaults, regions, or capabilities |
| 8 | Human-in-the-Loop | PASS | Review checklist provided below |

---

## 6. Review Checklist

- [ ] All 10 functional requirements trace to a DKM source section
- [ ] P0 priorities assigned to core sharing/management; P1 to audit/advanced
- [ ] All three use cases have complete process outlines
- [ ] Non-functional targets are quantified and measurable
- [ ] No invented requirements — every FR grounded in source
- [ ] No version-change language, no "deferred" notes, no scope-reduction references
- [ ] Constitution 8/8 — each principle has explicit evidence
- [ ] Stakeholder sign-off: ________________ Date: ________________