OPRP threat model, prototype 0.1

This threat model covers the executable prototype and the intended protocol boundaries. Passing internal tests does not establish independent cryptographic review, clinical safety, HIPAA compliance, or production readiness.

Assets and trust boundaries

Protect clinical bodies, search context, access and refresh credentials, private keys, authorization decisions, identity-to-key bindings, record integrity, operation receipts, audit history, and availability. Disclosure to an authorized requester is a real transfer of information: the protocol cannot erase a copy after that requester has received it.

flowchart LR
  P[Patient or representative] -->|Host-specific authenticated decision| H[Patient Host]
  A[Requester application] -->|Signed encrypted request over HTTPS| H
  H -->|Signed encrypted response over HTTPS| A
  D[Address domain / WebFinger] -->|Signed domain-to-Host delegation| A
  C[Independent credential authorities] -->|Identity and key credentials| A
  C -->|Requester credentials| H
  H --> S[Host-controlled storage and backups]

The Host and each authorized requester handle decrypted data. Their processes, administrators, storage, logs, backup systems, and endpoint devices are trusted for that handling. Payload encryption protects exchange across transport boundaries; it does not protect a patient from a malicious Host that was entrusted with plaintext. Host security assessment must cover at-rest protection and operations separately from protocol interoperability.

Authorities and root distribution are also trusted. A credential confirms only the identities and properties its issuer actually verified. It does not itself authorize access to a patient's records. Address authorities must be constrained to the domains they are permitted to certify. An address provider can select a Host only within its authentic delegation authority; provider-controlled address continuity remains a dependency on that provider.

Adversaries and controls

Explicit limitations

The prototype has no forward secrecy. Each message uses a fresh KEM encapsulation, but its recipient encryption private key is long-lived. Later compromise of that private key allows a recorded KEM ciphertext to be decapsulated and its recorded payload decrypted. Short message lifetimes and deletion of local symmetric-key buffers do not solve this. An authenticated ephemeral-session design, key-retention policy, and independent assessment are release gates.

The composition in the wire profile is experimental. Its primitives are standardized; that does not make this custom envelope standardized HPKE, a registered JOSE profile, or a FIPS-validated cryptographic module. No plaintext fallback exists, but there is no negotiation or upgrade mechanism yet.

Discovery reveals an account identifier and Host association. Envelope headers and credentials reveal sender/recipient identities, public keys, timing, and ciphertext length. The record identifier and authorization material travel inside encrypted exchange bodies, but discovery supplies the record binding openly in this prototype. Enumeration controls and a private-resolution design must be resolved before real patient deployments. HTTPS does not eliminate metadata visibility at operators.

The reference SQLite database stores clinical resources, authorization requests, receipts, events and audits in plaintext. Identity private keys remain in process memory; refresh lookup stores hashes and recovery additionally stores short-lived encrypted successor receipts. Cursor encryption keys are persisted as Host service secrets in the database. The SDK's optional persistence hook contains secrets and requires application-owned protection. Production key custody, hardware integration, database encryption, backup recovery, access controls and secrets handling are unfinished. The demo's generated TLS key is development-only and unrelated to payload post-quantum authentication.

Credential authorities are now constrained by identity kind, namespace, roles and validity. Authenticated signed status has bounded freshness, durable monotonic sequence/equivocation checks and persistent serial/key revocations; locally disabled issuers remain disabled after restart. Planned requester rotation requires old/new ownership proof and current credentials, pins current keys and retires old refresh credentials without expanding grants. Public enrollment, status retrieval workers, trust-list governance, issuer/Host-key rotation and compromise recovery remain unfinished. See credential lifecycle.

The Host uses synchronous SQLite and a bounded HTTP body, but those do not constitute a DoS defense. Invalid outer messages receive an empty transport error. Authenticated application errors are encrypted. Logs must avoid plaintext bodies and tokens; the current audit coverage includes successful record operations and token outcomes, and is not a complete security audit trail.

Same-ID refresh retries can recover the same unused successor within 120 seconds, including after a persisted-state and Host restart. Recovery never overrides revocation or extends authority. It refuses superseded or expired receipts, and different-ID reuse revokes the grant. Independent processes sharing an old credential still need coordination; the persistence hook is not a secure storage implementation. New requests, decision polling and explicit token replacement can currently issue additional refresh credentials for one grant, so family management and external recovery review remain work. See refresh recovery.

The reference slice accepts Patient name updates, limited laboratory Observations and six clinical types, with selected stricter admission, stable scoped baseline pages and ordered changes. It is not full FHIR validation, US Core, a treatment workflow, or clinical decision support. Signed full archives and independent encrypted offline restore work for the reference profile with retained history and operation receipts. Known source revocation still blocks archive verification; signed creation times are not externally notarized and offline readers may lack later compromise knowledge. Coordinated narrow-profile migration now uses inaccessible staging, durable same-transaction source fences, signed irreversible release/activation and verified monotonic discovery publication. Normal restart and lost-response recovery are tested. Stale database rollback, distributed custody and malicious operators remain outside its guarantee. Incremental/general archives, comprehensive label obligations and production notification operations remain open; logical clinical deletion and optional encrypted webhooks are implemented. See portability. Current baseline/search/history reads use bounded immutable sessions; local mirrors require at-rest custody and cannot detect unknown remote revocations while offline. See pagination and mirrors.

A signed release permanently fences the participating source database before destination activation. Restoring a pre-release source database can erase that local fence; the reference implementation does not offer rollback-resistant storage or distributed leases. Never interpret its normal restart evidence as proof against stale disaster-recovery copies or dishonest Hosts. Owner continuation after representative withdrawal cannot undo release. See migration conformance and recovery.

Review and release gates

Before a public production profile, freeze security objectives and required algorithms; adopt or have the combined construction independently reviewed; decide forward-secrecy behavior; test identity enrollment, rotation, revocation, and recovery; validate current-permission enforcement across all operations; exercise lost-response and process-failure recovery; and complete operational and clinical-profile validation. Each limitation must remain visible in documentation and conformance claims until its evidence exists.

Outbound callback boundary

Optional subscriptions introduce Host-initiated network requests. The default worker separates cryptographic callback control from destination permission: it requires HTTPS, denies URL credentials/query/fragment and nonstandard public ports, validates all resolved addresses with a conservative public-network policy, pins the socket and rejects redirects. A privileged exact-destination transport override exists for synthetic demonstrations or separately approved private integrations. DNS resolver deadlines, egress controls, policy maintenance, scheduler scaling and full audit/retention remain operator/release work.

Signed encrypted acknowledgments bind to the application keys and incoming message ID. Durable logical IDs/receipts prevent duplicate pull tasks after response loss; coalesced revision tracking protects concurrent wake-ups. Notifications contain no clinical values, patient/resource IDs, bearer tokens or feed counter. Outer identities, destination, timing and length remain observable. Live permission checks stop future delivery after revocation, rotation, representative withdrawal or source release, but cannot retract bytes already sent. The later data pull independently enforces current authority.