v0.21.0 scram password auth, cred and token management, browser tls-terminating proxy, viewer client

doc/README.md

@@ -20,8 +20,8 @@ streams, or downstream LogWisp nodes.
 | [Networking](networking.md) | Listeners, dialers, timeouts, connection limits |
 | [Security](security.md) | TLS, mTLS, and peer authorization; threat model and current limits |
 | [mTLS Authentication](mtls-auth-plan.md) | Design and rationale for certificate-based authorization |
-| [Password Authentication](scram-auth-plan.md) | Planned Argon2id-SCRAM design; mTLS hardening |
-| [CLI](cli.md) | Flags, signals, exit codes |
+| [Password Authentication](scram-auth-plan.md) | Design and rationale for Argon2id-SCRAM authentication; mTLS hardening |
+| [CLI](cli.md) | Flags, signals, exit codes, `logwisp auth` |
 | [Operations](operations.md) | Running, monitoring, tuning, troubleshooting |
 
 A fully annotated configuration covering every option lives at
@@ -63,8 +63,11 @@ endpoint), `tcp` (broadcast server), `null`, and the chain forwarders
   present a client identity
 - Authorization by certificate identity, per listener: named peers rather than
   everything the CA issued, with the `http` sink's endpoints gated too
+- Password authentication (Argon2id-SCRAM) bound to the listener's certificate,
+  with bearer tokens on HTTP listeners and a `logwisp auth` CLI, and browser
+  logins behind a TLS-terminating proxy
 - Node binding, so a chain source labels entries from the sender's certificate
-  rather than from what the sender claims
+  identity or username rather than from what the sender claims
 
 See [Security](security.md) for what each layer does and does not give you.