# OCP next-release security and privacy delta

> **Historical design record.** This analysis was written against the then-current OCP 0.2 review snapshot. Its retained recommendations informed OCP 0.4; “current” below means current at the time of this review unless a passage explicitly discusses 0.4.

**Review scope:** security/privacy disposition of `pasted-text-3.txt` and the governing revision brief in `pasted-text-4.txt`, checked against the current `OCP-v0.2-Review-Draft.md` and `OCP-Schema-and-Conformance-Pack`.

**Evidence boundary:** this is a read-only specification/package review. It does not establish implementation security, deployed authorization, parser containment, cryptographic correctness, independent interoperability, privacy-law compliance, or human consent quality. No file under `deliverables/` was changed.

## 1. Verdict

The current 0.2 design is materially safer and more coherent than the replacement architecture proposed in reviewer input 3. The next release should preserve these current decisions:

- `context_request` is inert, `grant_receipt` is a non-secret decision record, and the deployment authorization system remains the actual enforcement layer;
- context, evidence, and artifact content remain separate disclosure views;
- package content stays in a data channel and never becomes policy, tool, credential, or external-action authority;
- baseline delegation is exactly `none`;
- imports use raw, parsed, mapped, and accepted trust zones, and parsing or signature validity never creates acceptance;
- raw source bytes are preserved or explicitly loss-reported rather than destructively “sanitized” in place;
- remote/offline cryptographic conformance remains unavailable until a registered profile and executable vectors exist;
- revocation, reported deletion, cryptographic erasure, and independent verification remain distinct claims; and
- CloudEvents remains an optional notification binding, not the authoritative state or mandatory audit-storage format.

The next release should **not** be a reviewer-3 rewrite. It should close a smaller set of concrete release blockers in the current architecture. The most important are exact snapshot binding across revisioned records, an explicit distinction between the one delivery recipient and every approved plaintext processor, typed package-entry validation, a non-circular offline protection envelope, evidence-backed source verification states, explicit JSON/JCS processing constraints, bounded proposal rights, and assertion-by-assertion evidence reporting.

## 2. Reviewer-input disposition

| Reviewer 3 recommendation | Decision | Security/privacy reasoning | Next-release treatment |
|---|---|---|---|
| Remove an OCP bearer-style grant | **Underlying concern accepted; proposed mechanism rejected** | The current `grant_receipt` already fixes the concern without becoming a credential. Moving the decision into access-token claims would leak detailed context semantics into token infrastructure, couple OCP to one authorization family, and blur evidence with authority. | Keep `grant_receipt`; bind it to an exact request snapshot and external/local authorization reference; authorize each operation independently. |
| Represent all OCP requests as OAuth RAR and mandate RAR for every HTTP deployment | **Rejected as core requirement** | RAR is a useful remote OAuth carrier, not the OCP state model. Local IPC, OS brokers, GNAP, and other bindings remain legitimate. Many authorization servers also cannot safely compare arbitrary authorization-details JSON. | Make RAR normative only inside a registered OAuth/RAR Binding Profile with typed comparison and negative vectors. |
| Put grant decisions in OAuth access-token claims | **Rejected** | Self-contained tokens become privacy-rich dossiers, are hard to revoke precisely, and invite authorization by token-field presence. | Use opaque or minimal tokens/capabilities; keep full receipt semantics at the provider; bind token/capability to resource, operation, client instance, and active receipt. |
| Merge OCP discovery into OAuth Protected Resource Metadata | **Rejected** | RFC 9728 has its own schema and semantics. Polluting it with OCP profile/schema metadata risks incompatible implementations. | Keep `/.well-known/ocp-configuration`; link to protected-resource metadata and compare issuer/resource exactly. |
| Split one universal envelope into resource/message envelopes | **Accepted with modification, already substantially implemented** | Persistent records need the OCP record envelope, while discovery, Problem Details, CloudEvents, and archive manifests should use their native envelopes. A new generic `MessageEnvelope` would add little value and could force irrelevant fields again. | Retain the present object-specific approach; do not create a second universal envelope. |
| Rename “Canonical Context” to scoped accepted context | **Accepted and already implemented** | “Canonical” implies objective or global truth. | Keep `accepted context`; reserve canonicalization for bytes only. Do not reintroduce reviewer 3's `canonical_status` field. |
| Add a `quarantine_item` wrapper for every import and proposal | **Partially accepted** | Quarantine is a trust/state boundary, not necessarily a portable object. A universal wrapper can hide the raw/parsed/mapped distinction and encourage “sanitization means trusted.” | Keep the four trust zones and lifecycle. Add a profile object only if two implementations need to exchange quarantine metadata. Proposals remain inert and separately reviewable. |
| Strip markup, code blocks, or instruction-looking text during quarantine | **Rejected as unsafe** | Phrase stripping is bypassable, destroys evidence, breaks digests and round trips, and creates false confidence. Code blocks and markup can be legitimate user data. | Preserve exact raw bytes; create a separately identified safe-rendering derivative; escape/sandbox display; keep both raw and derivative untrusted. |
| Require AES-256-GCM “using the recipient public key” for every offline package | **Rejected** | AES-GCM is symmetric; public-key recipient encryption requires a complete hybrid construction. Algorithm pinning without key agreement, nonce, header authentication, multi-recipient, rotation, and downgrade rules is dangerous. | Register a complete recipient-encryption profile only after vectors. The core requires a registered profile, not a hand-written AES rule. |
| Require DPoP for all clients and treat it as non-forwarding protection | **Rejected as universal rule** | DPoP sender-constrains a token; it does not stop an authorized client from forwarding plaintext. Some deployments use mTLS, OS-bound capabilities, or local app keys. | Require sender constraint where the selected remote profile demands it; state that plaintext control remains declared/attested/audited unless separately enforced. |
| Use audience constraints and pairwise identifiers | **Accepted, but current rules need tightening** | Current pairwise/package-local rewriting is correct, but `audience` arrays conflate the delivery client, its instance, model providers, subprocessors, and independently acting recipients. One encryption binding cannot prove controls over all of them. | Split one cryptographic delivery recipient/client instance from the complete approved plaintext-processing-recipient set. Multiple independent delivery recipients get separate packages. Define alias generation using CSPRNG or a domain-separated keyed PRF. |
| Require a digest and independent copy before calling an artifact preserved | **Accepted and already stronger in current draft** | Current custody modes, byte digest, size, verification time, and source-dependency fields avoid URL-as-preservation claims. | Retain current Artifact Profile; add failure vectors for stale verification and byte mismatch. |
| Mandate one CloudEvent for every transition | **Rejected** | An audit record is required, but CloudEvents is a delivery envelope. Requiring it in the core couples storage/state semantics to a notification transport and encourages treating arrival order as truth. | Require an immutable audit transition record; allow CloudEvents as a reference-first binding. |
| Define tombstoned as “underlying record data has been purged” | **Rejected** | A tombstone cannot prove deletion from logs, backups, derivatives, recipients, or model weights. | Keep the current minimal anti-resurrection tombstone and qualified erasure evidence. |
| Move erasure records into generic audit events | **Rejected** | Deletion evidence needs target, scope, reporter, exclusions, limitations, method, and verifier relationship. An event is neither the evidence object nor the state of record. | Keep the Erasure Status Profile and reference it from privacy-safe events. |
| Standardize SD-JWT/BBS+ selective disclosure in core | **Deferred** | Arbitrary OCP graphs, arrays, external artifacts, accepted-state history, and revocation do not map cleanly to one credential disclosure system. Premature selection adds linkability and implementation risk. | Optional future profile after realistic graph/array/artifact/linkability experiments and independent implementations. |
| Publish 0.2 as approved/secure based on the reviewer scorecard | **Rejected** | A prose scorecard and synthetic schema tests are not independent interoperability or security evidence. | Preserve review-draft status and explicit unavailable conformance classes until evidence exists. |

## 3. Security and privacy delta register

Priorities below are **next-release gates**, not claims of an exploitable deployed product.

| ID | Priority | Finding | Current evidence | Required disposition |
|---|---:|---|---|---|
| SECDELTA-001 | P0 | Security-significant references bind only a URI, although resources are revisioned. A receipt can name a request ID without the exact request revision/digest; a package similarly names a receipt ID, and an accepted item names a decision ID. | `grant-receipt.schema.json:34`; `context-package.schema.json:32`; `context-request.schema.json:29`; `context-item.schema.json:63`. The prose requires named snapshots/revisions but the wire fields cannot express them. | Introduce exact snapshot references and separate them from live status references. Bind request, client declaration, receipt, decision, proposal, and source revisions/digests into the covered package view. |
| SECDELTA-002 | P0 | `audience` does not distinguish the one cryptographic delivery client/instance from model providers, subprocessors, or independently acting recipients that may receive plaintext. This conflicts with pairwise aliasing, recipient encryption, and baseline `delegation: none`. | `context-package.schema.json:34-38` and `grant-receipt.schema.json:59-63` allow arrays; semantic fixtures compare only the first audience. Sections 16.7 and 27.4 simultaneously prohibit forwarding and expect model-provider/subprocessor disclosure. | Define exactly one `delivery_recipient` and client-instance binding, plus a separately approved `processing_recipients` set covering every entity expected to receive plaintext. Issue separate packages to independent delivery recipients. Define whether subprocessing is distinct from delegation and enforce that distinction. |
| SECDELTA-003 | P0 | Package entry `content` is any JSON object and `layer`/`disclosure` combinations are not conditionally typed. Schema-valid `{}` evidence or an artifact marked `accepted` can pass the shape schema. Renderings also lack the explicit untrusted-data marker. | `context-package.schema.json:60-85`, especially lines 67-77; renderings at lines 87-104. | Require a content schema/media binding and conditional layer/disclosure rules. A core accepted-context entry must validate as `context_item`; profile entries must name a supported schema. Add `instruction_treatment: untrusted_data` to renderings. |
| SECDELTA-004 | P0 | The proposed offline signature layout is circular: the manifest lists `security/manifest.sig` with its digest while the prose says the signature covers the manifest and complete entry set. A signature cannot cover a manifest that contains the digest of that same signature without a defined excluded view. | Section 30.4 and the positive offline manifest; `offline-package-manifest.schema.json:18-52`. The suite correctly marks crypto unavailable but the target construction is still ambiguous. | Redesign the archive protection envelope before registering XFR-004. Define payload entries, security members, exact signed view, encryption/signing order, protected metadata, and archive-member equality without self-reference. |
| SECDELTA-005 | P0 | Current reports pass 44 semantic cases but cover only 13 of 54 assertion IDs; the other assertions are not machine-labeled `not_executed`, `manual_required`, or `unavailable` one by one. | `semantic-validation-report.json` lists 13 covered IDs. `availability.json` marks only Remote Security and offline-transfer protection unavailable. The prose honestly warns about narrow coverage, but machine consumers can still overread `automatable: true`. | Publish an assertion-results manifest with one status and evidence reference for every assertion. No assertion absent from executed evidence may appear as passed. |
| SECDELTA-006 | P1 | Source trust labels can claim `provider_signed` or `credential_verified` without required verification evidence, profile, covered digest, verifier, issuer, key status, or time. | `source-record.schema.json:35` is an enum only. | Rename the states to evidence-specific terms and conditionally require a verification-evidence snapshot. A signature proves covered bytes and issuer control only, not truth, authority, safety, or acceptance. |
| SECDELTA-007 | P1 | The package digest text is fixture-specific and the schemas make RFC 8785 metadata optional. OCP also lacks UTF-8/I-JSON and numeric interoperability rules while `number` and `quantity.value` accept arbitrary JSON numbers. | Section 13.5; `common.schema.json:239-240, 266-268, 310-318`; the reference validator implements a hand-written sorted-JSON routine. | Define exact JSON decoding, JCS eligibility, digest input, and number semantics normatively. Require conformant cross-language JCS vectors. Add a decimal-string/profile path for precision-sensitive values. |
| SECDELTA-008 | P1 | `proposal_rights` is a binary choice between `none` and `propose_only`; when enabled it authorizes create, revise, or withdraw without a wire-level selector for target space, predicates, sensitivity, evidence attachments, or operation. | `context-request.schema.json:42`, `grant-receipt.schema.json:69`, `context-package.schema.json:137`; Section 17.1. | Add bounded proposal constraints or narrow baseline semantics to included package items and explicitly approved create selectors. Recheck target/source authorization at submission and decision. |
| SECDELTA-009 | P1 | Accepted state requires only the presence of `decision_ref` and `accepted_scope`; the current executable semantic lane does not prove the decision exists, accepted this exact revision/result, or stayed within reviewer authority. | `context-item.schema.json:63-87`; CORE-006 is shape-oriented; the 13 covered semantic IDs do not include CORE-006/UPD-002. | Add exact decision snapshot linkage, resulting-item digest/ref equality, outcome checks, reviewer-authority checks, and negative fixtures. |
| SECDELTA-010 | P1 | Client declaration changes are a consent-time risk. The request names only a declaration URI; package construction does not carry the exact reviewed declaration revision/digest or an explicit live declaration-status check. | `context-request.schema.json:29`; Section 27.4 requires renewal after processor/model-provider changes, but the binding chain is not fully representable. | Bind the exact declaration snapshot into request and receipt; require active/unexpired status at issuance/dereference; suspend the receipt on material declaration change until new review. |
| SECDELTA-011 | P1 | Pairwise aliases are required but their unpredictability/domain separation is unspecified. An implementation could use an unkeyed hash of stable subject and audience IDs, enabling enumeration and cross-provider correlation. | Sections 13.2 and 27.2; PKG-005 tests non-reuse but not construction security. | Require CSPRNG mapping or a keyed, domain-separated PRF over provider, verified audience, client instance, scope/purpose domain, and rotation epoch. Do not encode raw IDs. |
| SECDELTA-012 | P1 | Archive rules do not explicitly require the physical ZIP member set to equal the manifest-declared set. Hidden/unlisted members, local-header/central-directory disagreement, trailing data, or duplicate encodings can bypass manifest review. | Sections 22.3 and 30.2 are strong but not exact on archive-member equality; schema validates only the manifest JSON. | Require exact set equality after decoding/normalization, reject unlisted members and header disagreement, and define treatment of ZIP64/data descriptors/trailing bytes. |
| SECDELTA-013 | P1 | `kind: instruction` remains a core context-item value. Even with `untrusted_data`, developers may promote a subject-approved “instruction” into a system/developer prompt, enabling instruction laundering. | `context-item.schema.json` kind enum; Sections 7.9, 10.4, and 20.4 contain the safety intent but not a kind-specific rule. | Rename to a less authoritative term such as `behavior_preference`, or normatively state that `instruction` is descriptive subject context only and can never acquire control-channel priority. Add an accepted-hostile-instruction test. |
| SECDELTA-014 | P1 | Audit/event guidance allows “digest” while prohibiting content. An unkeyed digest of low-entropy context or a stable artifact can be a dictionary oracle or cross-purpose correlation handle. | Sections 27.5 and 29.7. | Prohibit raw entry/content digests in general telemetry. Use opaque event-local/resource refs or purpose-scoped keyed commitments where correlation is needed; disclose equality leakage of artifact digests. |
| SECDELTA-015 | P1 | Raw secrets are prohibited in prose, but no named assertion/fixture demonstrates exclusion from sources, proposals, packages, renderings, errors, events, logs, or analytics. | Section 26.6 has the prohibition; no `SEC-*` assertion covers end-to-end secret exclusion. | Add a synthetic-secret containment assertion and multi-carrier fixtures with zero model/log/event/error disclosure as the expected result. |
| SECDELTA-016 | P2 | Time validation is incomplete as an interoperable algorithm: there is no registered clock-skew policy, future-issued limit, or assertion for every cross-field order. | Semantic validator checks several relations, but the suite has no case for `issued_at > expires_at`, future issuance beyond skew, invalid request range, or stale declaration/assurance at use time. | Define comparison instants and allowed skew per binding; add complete boundary fixtures. Wall-clock time still must not resolve write conflicts. |
| SECDELTA-017 | P2 | Third-party/organizational exclusions are strong in prose but thin in executable evidence. The assertion registry does not cover relationship/metadata leakage, mixed-source records, omission side channels, or multi-subject items. | PRIV-001/002 exist but are not in the 13-ID semantic coverage set. | Add policy fixtures for a second subject, raw third-party message, contact/location/health metadata, organization-managed provenance, coarsened omission, and non-disclosing errors. |

## 4. Target normative changes

The language below is intended as concrete input for the next clean specification, not as a patch against 0.2 wording.

### 4.1 Exact snapshot and live-status references

Define two distinct reference forms:

```json
{
  "id": "urn:uuid:...",
  "revision": 3,
  "schema_uri": "https://.../schema.json",
  "digest": "sha-256:..."
}
```

- A **snapshot reference** identifies immutable semantics and MUST include `id` and `revision`; when the object crosses a trust boundary it MUST also include the canonical digest and schema URI.
- A **live status reference** identifies the resource whose current status must be re-evaluated and MUST NOT substitute for the snapshot reference.
- A request MUST bind the exact client-declaration snapshot.
- A receipt MUST bind the exact request and client-declaration snapshots plus the external/local authorization decision.
- A package MUST bind the exact receipt snapshot used for construction and separately name/check the live receipt status resource.
- An accepted item MUST bind the exact review-decision snapshot; that decision MUST bind the exact proposal and resulting-item revision/digest.
- A consumer/provider MUST reject a revision, schema, or digest substitution before content processing. A same-ID/different-revision object is not the reviewed object.

### 4.2 Delivery recipient, processors, and delegation

- A Core runtime `context_package` MUST name exactly one cryptographic delivery recipient service and one authenticated client-instance binding.
- The request, declaration, receipt, and package MUST separately enumerate every model provider, subprocessor, or other processing recipient expected to receive plaintext. Missing lists mean undeclared, not none. Material change requires a new decision.
- A provider MUST create a distinct package, alias set, package-local ID set, integrity value, and recipient protection for each independent delivery recipient instance.
- The specification MUST define delegation as authority for an independently acting child principal. Declared subprocessing does not grant the processor OCP proposal, retrieval, transfer, or further-delegation rights, but plaintext disclosure to the processor still requires explicit approval and remains declared/contractual/attested unless technically enforced.
- Multi-recipient transfer is outside Core and requires a profile defining per-recipient keys, alias/linkability behavior, revocation, and removal.

### 4.3 Typed entries and inert renderings

- Every entry MUST name `content_schema_uri` when its content is structured JSON.
- An embedded core context entry with `layer: context` and `disclosure: accepted` MUST validate as a `context_item`, MUST contain a package-local item reference, and MUST pass accepted-decision linkage.
- Evidence and artifact entries MUST validate against their selected supported profile. Unknown critical schemas fail; unknown non-critical data is preserved/quarantined and is not rendered or disclosed.
- The schema MUST condition `disclosure` values on `layer` and reject impossible combinations.
- Every rendering MUST carry `instruction_treatment: "untrusted_data"`, digest, derivation references, media type, and language when known.
- Markdown/HTML/source content MUST be escaped or rendered in a sandboxed, non-scriptable view. Raw bytes remain available only through separately authorized quarantine/source inspection.

### 4.4 JSON and digest processing

- OCP JSON media types MUST use UTF-8 without a BOM. Parsers MUST reject invalid UTF-8, lone Unicode surrogates, duplicate member names, and any value outside selected I-JSON/JCS constraints before schema or digest processing.
- For embedded JSON, the entry digest MUST cover the exact RFC 8785 canonical form of the embedded value. The top-level package digest MUST cover the RFC 8785 canonical form of the complete package with only the defined `integrity` member omitted.
- `canonicalization` MUST be present and equal `RFC8785` whenever a digest covers JSON. Binary/reference digests cover exact bytes.
- The specification MUST define JSON-number handling consistent with RFC 8785/IEEE-754. Precision-sensitive decimal or integer values that cannot round-trip safely MUST use a canonical string/profile representation, not an unconstrained JSON number.
- The reference validator MUST use a conformant JCS implementation or publish proof-equivalent vectors; a locally sorted `JSON.stringify` helper is not sufficient conformance evidence.

### 4.5 Offline protection envelope

Before enabling XFR-004, define an archive construction with no self-reference. One defensible pattern is:

1. encrypt each non-public payload entry or a defined payload container to the exact recipient key under a registered AEAD/hybrid profile;
2. build a manifest over ciphertext payload paths, sizes, digests, schemas, and authenticated encryption metadata;
3. compute the canonical manifest digest over a view that excludes the detached signature object;
4. sign the manifest digest and required context/type/version domain separator;
5. place the detached signature in a separately declared security-member set; and
6. require the physical archive member set to equal `manifest + payload_entries + security_members` exactly.

The profile MUST define algorithm allowlists, key agreement, AEAD nonce rules, protected headers, recipient/client-instance binding, issuer trust, key status, `kid`/remote-key resolution, sign/encrypt ordering, multi-recipient behavior, metadata leakage, rotation, compromise, downgrade, and fail-before-release. It MUST reject `alg:none`, untrusted embedded verification keys, cross-object signature reuse, wrong content type, wrong issuer, wrong recipient, wrong client instance, revoked keys, modified external content, and weaker-profile substitution.

Do not standardize “AES-256-GCM with a public key” as shorthand for this construction.

### 4.6 Verification evidence, not trust labels

- Replace `provider_signed` with `signature_verified` and `credential_verified` with `credential_proof_verified`.
- Either value MUST require a verification-evidence snapshot naming verifier, verification profile/version, claimed issuer, covered object/byte digest, key or proof identifier, verification time, status/revocation method and time, result, and limitations.
- `source_provider` identifies the asserted source role; it MUST NOT be inferred from the signing key without profile validation.
- A successful proof MUST NOT change `instruction_treatment`, acceptance, sensitivity, disclosure authority, or external-action authority.

### 4.7 Bounded proposals

- Proposal authorization MUST be the intersection of active receipt, client instance, allowed operations, target/create selector, spaces, predicates/kinds, maximum sensitivity, source/evidence attachment rights, time, and local policy.
- Baseline `propose_only` SHOULD be replaced by a structured constraint or defined narrowly: revise/withdraw only package-present items within their accepted scope, and create only within explicit grant selectors.
- Proposal source references MUST already be authorized or enter a separate source-ingest quarantine. Raw credentials, tokens, unrelated source bytes, third-party content, and organization-managed data are rejected/quarantined.
- Review UI MUST escape all client text, isolate attachments/links, show the exact proposed diff and source, prevent deceptive bulk acceptance, and never treat silence or timeout as acceptance.
- Acceptance rechecks reviewer authority, target revision, sensitivity/profile rules, and exact resulting-item snapshot atomically.

### 4.8 Pairwise alias construction

- Package-local identifiers MUST contain at least 128 bits of CSPRNG unpredictability or equivalent.
- Stable audience-pairwise aliases MUST be randomly mapped or derived with a provider-secret, domain-separated PRF. The domain MUST include exact verified audience and client-instance identity and a version/rotation epoch; deployments SHOULD consider purpose/space separation where correlation is not required.
- Raw internal identifiers, public hashes of them, account IDs, email addresses, or reversible encodings MUST NOT appear in an alias.
- Rotation, backup/restore, provider compromise, subject merge/split, and mapping deletion behavior MUST be documented and tested.

### 4.9 Privacy-safe audit and telemetry

- Events and telemetry MUST NOT contain raw entry/content digests, stable subject aliases, purpose descriptions, filenames, relationship IDs, or any value that enables cross-purpose equality testing unless a specific authorized audit profile requires it.
- Use opaque event-local/resource references or purpose-scoped keyed commitments. Keys used for audit commitments MUST be separate from signing/encryption/alias keys and must rotate under a declared retention policy.
- Where a content digest must be disclosed for transfer verification, documentation/UI MUST state that equality and low-entropy dictionary attacks remain possible.

### 4.10 Assertion evidence manifest

For every registered assertion, publish exactly one current status:

- `executed_pass` with validator, implementation, input/vector, observed result, time, and evidence digest;
- `executed_fail` with the same evidence;
- `not_executed`;
- `manual_required` with evaluation method;
- `unavailable` with missing profile/dependency; or
- `not_applicable` with a scoped reason.

`automatable: true` means a test is possible, not that it exists or passed. Aggregate counts MUST be derived from the per-assertion records.

## 5. Required assertions and fixtures

The IDs are proposed additions or replacements; final numbering should be coordinated with the central assertion registry.

| Proposed assertion | Required fixtures / vectors | Required observable result |
|---|---|---|
| **BIND-001 Exact request snapshot** | Same request ID with wrong revision; same revision with wrong digest/schema; changed purpose description under same code | Reject before authorization/package construction; zero disclosed bytes. |
| **BIND-002 Exact declaration snapshot** | Expired/revoked declaration; processor/model-provider changed; same declaration ID with new revision | Receipt/package suspended or new review required; no package emitted. |
| **BIND-003 Exact receipt snapshot plus live status** | Wrong receipt revision/digest; active snapshot but current status revoked; stale status response | Reject package/dereference; no best-effort content use. |
| **BIND-004 Accepted-decision linkage** | Dangling decision; wrong proposal; non-accept outcome; resulting-item mismatch; decision scope/reviewer authority narrower than item | Item cannot become accepted or enter package. |
| **PKG-009 Delivery/processor separation** | Two independent delivery recipients; wrong client-instance thumbprint; undeclared model provider/subprocessor; processor changed after review; reused package for peer recipient | Reject; one delivery recipient per package, all plaintext processors explicitly approved, and separate package required for peer delivery. |
| **PKG-010 Layer/schema/disclosure binding** | `content:{}`; context+selected_content; artifact+accepted; schema URI/type mismatch; unknown critical entry schema | Schema/semantic rejection before rendering/model use. |
| **PKG-011 Inert rendering** | Prompt/tool text in plain text, Markdown links, HTML, SVG, filename, and rendering metadata | No policy/tool/network/action effect; safe display only. |
| **PKG-012 Pairwise construction** | Same subject for two audiences/instances/rotation epochs; internal-ID substrings; predictable counter/UUIDv1 construction | No reuse or reversible/internal correlation; generator evidence reviewed. |
| **JSON-001 Strict JSON** | UTF-8 BOM, invalid UTF-8, lone surrogate, duplicate member, excessive depth/string, non-finite parser extension | Reject before schema/digest evaluation. |
| **JCS-001 Cross-language canonicalization** | RFC 8785 official vectors plus key-order, escapes, Unicode, exponent, negative zero, 2^53 boundary, high-precision decimal cases in at least two independent language stacks | Identical canonical bytes/digests for allowed values; forbidden values rejected. |
| **CRYPTO-001 Signature type/issuer binding** | Bit tamper, added/removed payload, wrong issuer, wrong object type/profile/version, `alg:none`, algorithm substitution, embedded untrusted key, revoked/expired key | Reject before content release. |
| **CRYPTO-002 Recipient/client-instance binding** | Wrong recipient key, different instance of same client, removed protected header, replay to peer client, downgraded encryption profile | Decryption/use fails before plaintext reaches application/model. |
| **CRYPTO-003 Offline signed view** | Signature sidecar self-reference attempt; missing security member; unlisted archive member; changed manifest; changed ciphertext; signature/encryption metadata substitution | Exact-member and signed-view validation fails deterministically. |
| **TRUST-001 Verification evidence** | `signature_verified`/`credential_proof_verified` without evidence; wrong covered digest/issuer; stale status; verifier equals source where independence claimed | Reject verification label or downgrade to unassessed; never promote acceptance. |
| **UPD-004 Proposal attenuation** | Cross-space target, predicate outside grant, unauthorized withdraw, excessive sensitivity, unrelated source ref, evidence attachment without right | Proposal rejected/quarantined; accepted state unchanged. |
| **UPD-005 Proposal UI isolation** | HTML/Markdown/SVG/script URL, bidi controls, deceptive filename, hundreds of low-risk items mixed with one high-risk item | No active content; no hidden diff; no bulk acceptance of ineligible items. |
| **IMP-005 Archive exactness** | Hidden member, central/local header mismatch, duplicate normalized/case path, symlink/hardlink, absolute/Windows path, trailing bytes, nested ZIP bomb, MIME polyglot | Import remains quarantined or rejected; no write outside quarantine; no network/credential access. |
| **IMP-006 Hostile carrier containment** | Instructions in JSON keys/values, metadata, filenames, URL, image EXIF/OCR, audio transcript, PDF, code, nested archive, signed content, and subject-confirmed content | Zero change to policy, tools, network, accepted state, secrets, or external action. |
| **SEC-004 Secret containment** | Synthetic API keys, tokens, cookies, private keys, passwords, recovery codes in source/proposal/rendering/error paths | Excluded/quarantined from packages, models, embeddings, logs, events, analytics, and errors. |
| **PRIV-004 Third-party/organization boundary** | Second subject; private message; contact/precise location/health metadata; organization-managed source; mixed personal/work record | Omitted/quarantined under Core Personal; non-disclosing error/omission. |
| **PRIV-005 Material recipient change** | Subprocessor/model provider/retention/training/deletion capability changes after approval | Current receipt suspended/superseded; new visible decision required. |
| **EVT-002 Digest correlation** | Low-entropy content digest and stable artifact digest offered to event/OTel exporter | Raw digest rejected from general telemetry; approved keyed/opaque reference used. |
| **TIME-001 Complete temporal order** | `not_before >= expires_at`; package issued before grant/after package expiry; future issuance beyond skew; expired declaration/evidence; timezone-equivalent instants | Deterministic fail code; no lexical/local-time comparison. |
| **CONF-001 Complete result accounting** | Registry with one omitted/unexecuted assertion; false aggregate pass; manual assertion marked automated | Report fails completeness check and never counts missing/manual evidence as pass. |

The current hostile-import assertions (`IMP-001`/`IMP-002`), package-consumer checks (`PKG-006`/`PKG-007`), proposal assertions (`UPD-*`), privacy assertions (`PRIV-*`), and event/error assertions should remain, but they need executable evidence or an explicit non-pass status. Schema-only rejection is insufficient for claims about zero tool execution, zero network access, no parser escape, no sensitive leakage, or accessible consent.

## 6. Missing or under-recorded issues for the central review register

These should be added or explicitly linked to existing issues rather than duplicated:

1. **Revision/digest binding is systemic, not package-only.** Link to existing OCP-P0-002 and OCP-P1-010, then expand the fix to every security-significant reference.
2. **Delivery audience, processing recipients, and delegation are conflated.** New issue: multi-audience arrays conflict with one alias set and one client-instance encryption binding, while the prose both prohibits forwarding and anticipates model-provider/subprocessor receipt.
3. **Package entry schemas are not discriminated.** New issue: shape-valid arbitrary JSON and cross-layer disclosure values can pass the schema.
4. **Offline manifest signature self-reference.** New issue under existing crypto blocker OCP-P1-013/XFR-004.
5. **Source verification states lack evidence.** New issue: `provider_signed` and `credential_verified` are assurance overclaims without proof linkage.
6. **Unknown-extension “byte-for-byte” language is inconsistent with parsed JSON-value storage.** Clarify semantic JSON preservation versus opaque original bytes; signed opaque envelopes must remain byte-preserved or be re-signed with a loss record.
7. **JCS/I-JSON/numeric semantics remain open.** Expand existing OCP-P2-009 with UTF-8, surrogate, number precision, and cross-language vectors.
8. **Proposal authority is too coarse.** Expand OCP-P1-030 from rate limiting/UI to selector- and operation-level attenuation.
9. **Instruction-kind authority laundering.** New issue: accepted “instructions” need explicit descriptive-only semantics or a safer name.
10. **Audit digests can be personal-data correlators.** Expand OCP-P2-005 with dictionary/equality leakage and keyed/opaque alternatives.
11. **Archive member-set equality is not explicit.** Expand OCP-P1-015 beyond path traversal and bombs to hidden/unlisted members and ZIP parser differentials.
12. **Machine-readable test coverage can be overread.** New conformance-report issue: only 13/54 assertions are in the semantic report's coverage list; every assertion needs an evidence status.
13. **Accepted decision linkage lacks executable proof.** Expand CORE-006/UPD-002 and OCP-P0-002 to validate the exact outcome/resulting revision/reviewer authority.
14. **Secret containment lacks a named assertion.** New security issue: the prose prohibition needs end-to-end negative fixtures across all egress surfaces.
15. **Pairwise identifier construction is unspecified.** Expand OCP-P1-005 beyond non-reuse to unpredictability, domain separation, rotation, and compromise behavior.

## 7. Security/privacy release gates

The next authoritative package should not claim the affected class until all applicable gates pass:

1. Exact snapshot-reference schemas and substitution fixtures pass.
2. Core runtime delivery recipient is exactly one, its client instance is separately verified, and every plaintext processor is explicitly approved and bound into the decision chain.
3. All package entry types/disclosures are schema- and profile-bound; arbitrary JSON cannot masquerade as a typed entry.
4. A non-circular offline protection profile is registered and verified with independent positive/negative vectors, or XFR-004 remains explicitly unavailable.
5. Remote authenticity/confidentiality/client-instance profiles are registered and executed, or SEC-001/002 remain explicitly unavailable.
6. Strict JSON/JCS vectors pass in at least two independent language implementations.
7. The hostile import/archive corpus demonstrates bounded sandbox behavior and zero privileged effects; schema tests alone do not satisfy Import Safety.
8. Proposal attenuation and accepted-decision linkage pass cross-object tests.
9. Third-party, organization, client-declaration-change, secret-egress, and telemetry-correlation fixtures pass.
10. Every normative assertion has a machine-readable evidence status; aggregate pass counts include only executed passes.
11. At least one independent adversarial review covers the selected crypto profile, archive parser, local binding, and consent/recipient-change flow.
12. Public wording continues to distinguish structural conformance, deployed enforcement, independent interoperability, external assurance, legal review, and live human acceptance.

## 8. Bottom line

Reviewer input 3 correctly emphasized prompt injection, pairwise privacy, third-party exclusion, artifact integrity, and the separation of revocation from deletion. The current 0.2 draft already incorporates those concerns in a safer form. Its weakest remaining security points are not missing slogans; they are wire-level ambiguity and evidence gaps: floating revision references, conflated delivery/processor/delegation roles, untyped package entries, circular archive-signature coverage, unsupported trust labels, coarse proposal authority, incomplete JSON canonicalization rules, and incomplete executable assertion accounting.

Closing those points would materially improve the protocol without turning OCP into an authorization server, cryptographic invention, sanitizer, event system, or universal AI runtime.
