A15. Security requirements

spec 1.0-draft-1

Status: normative. Document version 1.0-draft-1.

The protocol minimises disclosure; it does not make a trusted host harmless or guarantee deletion by a recipient. Treat record contents and contributor text as untrusted data. They cannot override recipient system instructions, tool permissions or safety boundaries.

A15.1 Authority and isolation

Every recipient action requires current server-side authority. Enforce issuer, exact audience, client binding, expiry, the DPoP proof, grant revision, domain/key/level constraints, purpose, temporal validity and limits. Recheck inside the transaction. Deny missing, unknown or incompatible state. The privacy boundary covers errors, discovery, provenance, identifiers, metrics and conditional requests as well as entry values.

Use client-bound handles and entry aliases. A contributor cannot enumerate other recipients or learn where the person migrated. L0 categories are closed and reveal no direct value; combinations may still identify a person or imply sensitive information. Providers SHOULD refuse a wildcard L0 grant to a client already holding L2 or higher in any domain, and explain its actual grant selection to the person.

A15.2 Signed objects

Required signatures cover successful disclosure envelopes, owner-verifiable read receipts, export envelopes, purge instructions and purge acknowledgements where the recipient has a registered key. Reserved future host-binding formats must define their own signed object before use. TLS is still mandatory.

HTTP 204/304, operational health/readiness, errors, lists and discovery are not signed disclosure envelopes. MCP wraps the same signed object rather than an unsigned equivalent. This boundary replaces the earlier ambiguous phrase “every response signed”. Signature verification includes configured trust, protected type/algorithm, complete signed bindings, strict canonicalisation and deadline checks; see A5.

A15.3 Implementation controls

Use maintained cryptographic libraries and secure platform primitives. Private keys and encrypted record contents must be isolated from operational support access. Administrative actions are logged to affected owner history without exposing values.
Rate-limit by client, grant and unauthenticated origin. Bound nested JSON, body size, dependency depth, exports, cryptographic work and retries. Unavailable key storage or grant state fails closed with not_ready.
Fetch client-supplied URLs only through SSRF-safe retrieval, checking resolved addresses and redirects and blocking private/link-local destinations unless an explicitly isolated local mode is configured. No credential forwarding across origins.
Keep values, renderings, utterances, evidence, uploads, credentials and tokens out of operational logs, traces, metrics, emails and job payloads. Owner history is separately protected.
Protect first-party changes with authenticated sessions, CSRF controls, fresh re-authentication for sensitive actions and visible audit history. A first-party request without a current session fails session_required, one whose CSRF proof does not verify fails csrf_invalid, and a sensitive action without recent re-authentication fails reauthentication_required. A sign-in that does not succeed fails sign_in_failed whatever the reason, and a sign-up while the provider admits no new accounts fails signup_unavailable; neither depends on whether an address has an account. Never expose a route that decrypts arbitrary records for operators.

Version 1 excludes guardian-managed advertising and reserves general guardian/duress functionality. These need independent abuse, safeguarding and control-transfer designs before release. A plausible-looking “duress record” is not a security guarantee and must not be claimed from this draft.

Checks: all security-relevant checks in the manifest, including FETCH-01 and WILDCARD-01. Cryptographic interoperability, concurrency, storage and live authorisation remain runtime release gates.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.