Add sharing grant management flow

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+- Added incident-scoped sharing-grant management for active contact keys,
+  optional stream scope, optional expiry, and revocation.
 - Added account-level contact public-key management for create, update, and
   revoke flows.
 - Added owner incident deletion status and request UI for the authenticated

README.md

@@ -100,7 +100,7 @@ The current bootstrap includes:
 - incident detail metadata UI
 - stream and chunk metadata review
 - contact public-key metadata views and account-level management
-- sharing-grant metadata views
+- sharing-grant metadata views and incident-scoped management
 - wrapped-key metadata views
 - owner incident deletion status and request UI
 - safe loading, empty, and error states
@@ -149,8 +149,6 @@ The web client must not expose private admin/operator behavior or route `/v1/adm
 
 Planned sharing/contact work includes:
 
-- sharing-grant creation and revocation
-- incident-scoped and stream-scoped grant management
 - wrapped-key metadata review and delivery status
 - clear warnings that wrapped-key metadata is access-enabling metadata
 - trusted-contact access design, once separately scoped and threat-modeled

docs/api-client.md

@@ -47,8 +47,10 @@ From current `open-proofline/server` docs and route registration:
 - `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`
+- `POST /v1/incidents/{incident_id}/sharing-grants`
 - `GET /v1/incidents/{incident_id}/sharing-grants`
 - `GET /v1/sharing-grants/{grant_id}`
+- `POST /v1/sharing-grants/{grant_id}/revoke`
 - `GET /v1/incidents/{incident_id}/wrapped-keys`
 - `GET /v1/wrapped-keys/{wrapped_key_id}`
 
@@ -125,6 +127,26 @@ 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`.
 
+Sharing-grant management uses the server's authenticated owner-scoped routes:
+
+- `POST /v1/incidents/{incident_id}/sharing-grants`
+- `GET /v1/incidents/{incident_id}/sharing-grants`
+- `GET /v1/sharing-grants/{grant_id}`
+- `POST /v1/sharing-grants/{grant_id}/revoke`
+
+The client creates grants only from active contact public keys already returned
+for the active session. It sends tightly shaped request bodies for `contact_id`,
+optional `contact_public_key_id`, optional `stream_id`, `data_class`, and
+optional future `expires_at`. Missing incident, stream, or active contact-key
+dependencies stay generic in the UI as `sharing_grant_dependency_not_found`.
+
+Sharing grants authorize metadata and/or encrypted evidence access. They do not
+decrypt media, create trusted-contact sessions, notify emergency services, or
+guarantee emergency response. The UI marks expired or revoked grants as inactive
+delivery paths and does not retain wrapped-key ciphertext, raw media keys,
+contact private keys, plaintext, request bodies, stored paths, object keys, or
+private deployment details from grant responses.
+
 ## Public Registration Contracts
 
 The API client includes typed public calls for `POST /v1/auth/register` and

docs/security-model.md

@@ -19,6 +19,9 @@ This web client is experimental and not production-ready.
   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.
+- Sharing-grant management uses active contact public keys only, keeps expired
+  or revoked grants out of active delivery paths, and does not add decryption,
+  notification, or emergency-response behavior.
 - 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