Header numbering

README.md

@@ -52,13 +52,13 @@ UCAN MUST be used as the handshake signature envelope for AWAKE. Any UCAN-compat
 
 The [ECDH handshake][ECDH Input] MUST use [X25519].
 
-### 2.3.2 Symmetric Keys
+### 2.1.1 Symmetric Keys
 
 All symmetric encryption in the pre-MLS AWAKE handshake MUST use [XChaCha-Poly1305]. These keys MUST be generated by the [AWAKE KDF], and SHOULD be non-extractable where possible.
 
 Each encrypted payload MUST include a unique 24-byte [initialization vector][IV].
 
-### 2.3.3 Diffie-Hellman Key Derivation
+### 2.1.2 Diffie-Hellman Key Derivation
 
 AWAKE MUST use [HKDF] to derive keys. Key derivation in the AWAKE handshake MUST use the following algorithms:
 
@@ -71,7 +71,7 @@ FIXME
 
 The shared secret MUST be generated using [X25519]. Non-extractable keys SHOULD be used where available. The sender MUST rotate their public key on every send.
 
-## 2.4 Messagaging Layer Security
+## 2.2 Messagaging Layer Security
 
 After the AWAKE handshake, the protocol switches over to the Messaging Layer Security ([MLS]) protocol with UCAN credentials. MLS establishes an efficient post-comporimise security channel with group management.
 
@@ -248,7 +248,7 @@ flowchart LR
 
 Upon receipt, the Requestor MUST validate that the UCAN capabilities in the proof fulfill their `caps` criteria. The UCAN itself MUST be valid, unrevoked, unexpired, and intended for the temporary DID (the `aud` field). If any of these checks fail, the session MUST be abandoned, the temporary DID regenerated, and the protocol restarted from [intention broadcast](#32-requestor-broadcasts-intent).
 
-### 5.2.2 Payload
+### 5.2.1 Payload
 
 To start the Double Ratchet, the payload in this stage has the highest number of cleartext fields. Note that the value in the `iss` field contain the temporary ECDH DIDs, and MUST NOT use the Provider's actual long-term DID. Conversely, the UCAN inside the encrypted payload MUST use the Provider's long-term DID.
 
@@ -260,7 +260,7 @@ To start the Double Ratchet, the payload in this stage has the highest number of
 | `aud`  |               | The X25519 DID signalled by the Requestor in [§3.2](#32-requestor-broadcasts-intent)     | Yes      |  FIXME!!!!!!!!!!!!!!!!
 | `msg`  |               | Nullipotent validation UCAN encrypted with XChaCha-Poly1305                              | Yes      |
 
-#### 5.2.2.1 JSON Example
+#### 5.2.1.1 JSON Example
 
 ``` javascript
 {
@@ -272,13 +272,13 @@ To start the Double Ratchet, the payload in this stage has the highest number of
 }
 ```
 
-### 5.2.1 Nullipotent UCAN
+### 5.2.2 Nullipotent UCAN
 
 The Provider's UCAN MUST NOT be used to delegate any capabilities to the Requestor at this stage. This UCAN MUST only be used to prove access to capabilities. The issuer (`iss`) field MUST contain the Provider's long-term DID (rather than the temporary ECDH DID). The audience (`aud`) field MUST contain the Requestor's _temporary_ ECDH DID from the previous step.
 
 This UCAN MUST be encrypted with a HKDF-generated XChaCha-Poly1305 key plus IV before being placed into the payload (below).
 
-#### 5.2.1.1 Challenge
+#### 5.2.2.1 Challenge
 
 The Provider MUST set the method of challenge to validate the Requestor. This MUST be set in the `fct` section of the UCAN so that it is signed by the Provider. The RECOMMENDED authorization methods are out-of-band PIN validation (`oob-pin`) and UCAN (`ucan`).
 
@@ -303,7 +303,7 @@ To set the challenge as `ucan`, the `fct` section of the UCAN MUST include the f
     ...,
     { 
       "awake/challenge": "ucan",
-      "caps": [...requiredCaps] 
+      "cap": {...requiredCaps}
     }
   ]
 }