Separate bearer ids from private tokens

README.md

@@ -98,9 +98,9 @@ The bootstrap implementation provides:
 - `geth secret bearer create <resource> --capability <capability>`
 - `geth secret bearer list`
 - `geth secret bearer challenge <resource> --capability <capability>`
-- `geth secret bearer prove <secret> <resource> --nonce <nonce> --capability <capability>`
-- `geth secret bearer verify <secret> <resource> --nonce <nonce> --response <response> --capability <capability>`
-- `geth secret bearer revoke <resource> <secret>`
+- `geth secret bearer prove <token> <resource> --nonce <nonce> --capability <capability>`
+- `geth secret bearer verify <token> <resource> --nonce <nonce> --response <response> --capability <capability>`
+- `geth secret bearer revoke <resource> <bearer-id>`
 - `geth auth explain <subject> <resource> <capability>`
 - `geth auth grant <subject> <resource> <capability> [--grant-id <id>]`
 - `geth auth revoke <resource> <grant-id>`
@@ -158,8 +158,10 @@ fetches record the serving peer as a local provider, visible with
 `geth cas providers <hash>`. This is the bootstrap transfer path; future work
 will move provider/fetch behavior to `iroh-blobs`.
 Remote resource commands that accept `--bearer-secret` can also authorize with a
-resource-scoped bearer proof. This does not enroll the caller as a trusted node;
-it only unlocks the requested capability on that one resource.
+resource-scoped bearer proof generated from the private bearer token returned at
+creation time. The persisted auth log stores a public bearer id and token
+verifier, not the private token. This does not enroll the caller as a trusted
+node; it only unlocks the requested capability on that one resource.
 `geth ssh cert sync <node-id>` requires `ssh_cert.sync` on `resource:ssh:certs`
 at the peer. `geth ssh revocation sync <node-id>` requires
 `ssh_revocation.sync` on `resource:ssh:revocations`. Both commands merge