Original text:
5.1. The "Signature" HTTP Authentication Scheme uses asymmetric <del> cryptography.  User agents possess a user ID and a public/private key pair, and origin servers maintain a mapping of authorized user IDs to their associated public keys.  When using this scheme, the "u", "p", </del>  and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using Ed25519 </del>  ED25519 could produce the following header field (lines are folded to fit): 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography. <del> User agents possess a user ID and a secret key, and origin servers maintain a mapping of authorized user IDs to their associated secret key.  When using this scheme, the "u", "p", and "h" parameters are </del>  REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using HMAC-SHA-512 </del>  SHA could produce the following header field (lines are folded to fit):

Reviewer comments:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Revised text:
5.1. The "Signature" HTTP Authentication Scheme uses asymmetric  <ins> cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys.  When using this scheme, the "k", "p", </ins> and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive.  <ins> For example, the key ID "basement" authenticating using Ed25519 </ins> ED25519 could produce the following header field (lines are folded to fit): 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography.  <ins> User agents possess a key ID and a secret key, and origin servers maintain a mapping of authorized key IDs to their associated secret key.  When using this scheme, the "k", "p", and "h" parameters are </ins> REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive.  <ins> For example, the key ID "basement" authenticating using HMAC-SHA-512 </ins> SHA could produce the following header field (lines are folded to fit):