Add contact public-key management flow

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+- Added account-level contact public-key management for create, update, and
+  revoke flows.
 - Added owner incident deletion status and request UI for the authenticated
   incident detail route.
 - Added an authenticated account profile route with safe account metadata and

README.md

@@ -99,7 +99,7 @@ The current bootstrap includes:
   owner-scoped `GET /v1/incidents` responses in live mode
 - incident detail metadata UI
 - stream and chunk metadata review
-- contact public-key metadata views
+- contact public-key metadata views and account-level management
 - sharing-grant metadata views
 - wrapped-key metadata views
 - owner incident deletion status and request UI
@@ -149,8 +149,6 @@ The web client must not expose private admin/operator behavior or route `/v1/adm
 
 Planned sharing/contact work includes:
 
-- contact public-key registration and management
-- contact public-key state display
 - sharing-grant creation and revocation
 - incident-scoped and stream-scoped grant management
 - wrapped-key metadata review and delivery status

docs/api-client.md

@@ -42,8 +42,11 @@ From current `open-proofline/server` docs and route registration:
 - `GET /v1/incidents/{incident_id}`
 - `POST /v1/incidents/{incident_id}/deletion`
 - `GET /v1/incidents/{incident_id}/deletion`
+- `POST /v1/contact-public-keys`
 - `GET /v1/contact-public-keys`
 - `GET /v1/contact-public-keys/{public_key_id}`
+- `PATCH /v1/contact-public-keys/{public_key_id}`
+- `POST /v1/contact-public-keys/{public_key_id}/revoke`
 - `GET /v1/incidents/{incident_id}/sharing-grants`
 - `GET /v1/sharing-grants/{grant_id}`
 - `GET /v1/incidents/{incident_id}/wrapped-keys`
@@ -101,6 +104,27 @@ but this metadata-review prototype keeps only wrapped-key identifiers, grant and
 contact bindings, wrapping metadata, and state until a separate trusted-contact
 delivery flow is designed and reviewed.
 
+Contact public-key management uses the server's authenticated account-scoped
+routes:
+
+- `POST /v1/contact-public-keys`
+- `GET /v1/contact-public-keys`
+- `GET /v1/contact-public-keys/{public_key_id}`
+- `PATCH /v1/contact-public-keys/{public_key_id}`
+- `POST /v1/contact-public-keys/{public_key_id}/revoke`
+
+The client sends tightly shaped request bodies for display label, wrapping
+algorithm, public key, fingerprint, optional `contact_id`, and reviewed
+`key_state`. It does not send or retain contact private keys, raw media keys,
+plaintext, wrapped-key ciphertext, browser fragment secrets, request bodies,
+stored paths, object keys, or private deployment details.
+
+Contact-key states are `pending_verification`, `active`, `replaced`, `revoked`,
+and `lost`. Only `active` keys are eligible for new sharing grants. The UI keeps
+revoked keys visibly ineligible and does not offer reactivation controls for
+revoked records; the server also rejects revoked-key reactivation with
+`409 invalid_contact_key_state`.
+
 ## Public Registration Contracts
 
 The API client includes typed public calls for `POST /v1/auth/register` and

docs/security-model.md

@@ -17,6 +17,8 @@ This web client is experimental and not production-ready.
 - API responses are parsed with Zod before use where route shapes are known.
 - UI states avoid showing raw tokens, Authorization headers, request bodies,
   plaintext, raw keys, wrapped-key ciphertext, stored paths, or object keys.
+- Contact public-key management sends only reviewed public-key metadata fields
+  and keeps revoked keys visibly ineligible for new sharing grants.
 - Registration responses use the server's generic verification-required success
   message and do not create a browser session.
 - The email-verification route reads the token from the URL fragment, submits