diff --git a/102.md b/102.md
index 633da2a0..060fdc37 100644
--- a/102.md
+++ b/102.md
@@ -27,12 +27,9 @@ The parent key can publish a `Kind 10102` event for subkey management. This even
 Content:
 ```json
 {
-  "keys": {
-    "<hex-subkey0-pubkey>": { "active_at": "<epoch-timestamp>" },
-    "<hex-subkey1-pubkey>": { "active_at": "<epoch-timestamp>", "revoked_at": "<epoch-timestamp>" },
-    "<hex-subkey2-pubkey>": { "active_at": "<epoch-timestamp>" }
-  },
-  "default_policy": "allow"
+  "inbox_keys": ["<hex-subkey0-pubkey>", "hex-subkey2-pubkey"],
+  "revoked_keys": ["<hex-subkey1-pubkey>"],
+  "other_keys": ["<non-derived-subkey>"]
 }
 ```
 
@@ -45,8 +42,8 @@ When signing events using a subkey, the account pubkey and subkey derivation pat
   "pubkey": "<hex-subkey1-pubkey>",
   "kind": 1,
   "tags": [
-    ["account", "<hex-account0-pubkey>", "<subkey1-derivation-path>"],
-  ],
+    ["I", "<hex-account0-pubkey>", "<subkey1-derivation-path>"],
+  ]
 }
 ```
 
@@ -55,18 +52,34 @@ For clients that don't implement NIP-102, we can have the account key publish a
 Content:
 ```json
 {
-  "account": "<hex-account0-pubkey>",
+  "account_key": "<hex-account0-pubkey>",
   "derivation_path": "<subkey1-derivation-path>"
 }
 ```
 
+## Migration
+
+Most current keys do not use BIP-39 derivation and will need to publish a `Kind 10102` event pointing to a new pubkey:
+
+```json
+{
+  "other_keys": ["<non-derived-subkey>"]
+}
+```
+
+The new key must publish the opposite `Kind 10102` event claiming the parent:
+
+```json
+{
+  "account_key": ["<parent-pubkey>"]
+}
+```
+
 ## Behavior
 
 All searches for the account pubkey should return those signed by any account subkey. If an event is replaceable, it is up to the client or relay as to whether both messages are maintained, or if only the latest across all subkeys is maintained. In any situation where data will be lost, a reasonable effort should be made to locate the most recent revocation list before proceeding.
 
-## Migration
-
-Most current keys do not use BIP-39 derivation and will need to perform a manual key rotation to a new pubkey using a method not defined here.
+Do not attempt to resolve `other_keys`, as this could grow exponentially. Always work up from the subkey, as each key can only have a single `account_key`. Limit any search to a reasonable constant maximum depth, maybe 8. If the maximum depth is reached, use the original key instead of the most recently found.
 
 ## Reference Code
 
diff --git a/README.md b/README.md
index 9f456fa8..61a63eaf 100644
--- a/README.md
+++ b/README.md
@@ -244,6 +244,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `g`               | geohash                              | --                              | [52](52.md)                           |
 | `h`               | group id                             | --                              | [29](29.md)                           |
 | `i`               | external identity                    | proof, url hint                 | [39](39.md), [73](73.md)              |
+| `I`               | parent of subkey                     | pubkey (hex)                    | [102](102.md)                         |
 | `k`               | kind number (string)                 | --                              | [18](18.md), [25](25.md), [72](72.md) |
 | `l`               | label, label namespace               | --                              | [32](32.md)                           |
 | `L`               | label namespace                      | --                              | [32](32.md)                           |