# Standards delta and mapping priorities for OCP 0.4

**Snapshot date:** 2026-08-12  
**Scope:** version and maturity changes that affect the next OCP release; primary/official sources only  
**Companion registry:** `registries/standards.json`  
**PAM mapping:** `mappings/PAM-v1.0.md`

## 1. Release-level conclusion

OCP 0.4 should continue to define its own narrow governed-context semantics while composing with established formats and protocols. It should not redefine generic authorization, agent transport, provenance, credentials, event envelopes, telemetry, or media authenticity. The release needs exact version pins and explicit semantic gaps, because several adjacent agent standards are dated or fast-moving and several identity sources are drafts rather than standards.

The highest-overlap work remains PAM 1.0. A field-level map now shows that PAM can be a strong source/export representation, but it cannot preserve OCP's scoped acceptance, review decision, client declaration, disclosure request, non-credential receipt, purpose-bound runtime package, or proposal workflow without a sidecar and explicit loss reporting.

## 2. Priority order

### P0 - required before an interoperability claim

1. **PAM 1.0 executable mapping.** Turn `pam-v1.0-mapping.md` into a versioned experimental profile with deterministic import/export rules, a machine-readable field map, loss-report schema, and the twelve minimum positive/negative/round-trip fixture classes listed there. Do not call the map lossless or bidirectionally interoperable until those fixtures pass.
2. **OAuth remote authorization binding.** Pin RFC 6749 plus BCP 240/RFC 9700, Authorization Server Metadata RFC 8414, RAR RFC 9396, Protected Resource Metadata RFC 9728, Resource Indicators RFC 8707, and DPoP RFC 9449 where sender-constraining is selected. Define exact typed containment, resource/audience equality, partial approval, current token/status checks, and client-instance binding. Preserve the rule that the OCP `grant_receipt` is non-secret and non-credential.
3. **Deterministic JSON profile.** Normatively pin JSON Schema 2020-12, RFC 7493 I-JSON constraints, and RFC 8785 JCS for every covered digest view. Specify duplicate-name rejection, Unicode handling, number range/serialization, UTF-8, timestamps, schema catalogs, covered members, and official vectors. A schema pass alone is not semantic conformance.
4. **HTTP discovery and error schemas.** Reuse RFC 8414/RFC 9728 for authorization metadata and RFC 9457 for HTTP problems. Publish stable OCP discovery/error extension fields and negative cases. Do not wrap Problem Details in the OCP persistent-record envelope.

### P1 - required for named profile claims

5. **PROV mapping.** Map OCP source records, interpretations, items, actors, revisions, activities, derivations, generation/use/invalidation, and qualified roles to the W3C Recommendation. State which OCP acceptance/review/disclosure semantics have no PROV equivalent.
6. **Artifact/C2PA mapping.** Pin C2PA 2.4 and map artifact descriptor, lineage, ingredients/actions, content binding, validation results, redaction, and repository receipts. Keep authenticity and validation separate from truth, rights, acceptance, and preservation.
7. **Credential/selective-disclosure profile.** Pin VC Data Model 2.0 and Data Integrity 1.0 Recommendations plus RFC 9901 SD-JWT. Require distinct issuer, holder, subject, verifier, proof result, status result, issuer-purpose trust, OCP acceptance, and external authorization states.
8. **MCP and A2A carriage bindings.** Pin MCP 2026-07-28 and A2A specification 1.0.0/protocol 1.0. Define media types, reference/digest rules, capability negotiation, error mapping, authorization handoff, and task/message/artifact carriage. Tool availability, task state, or authenticated agent identity must never imply accepted context or domain-action authority.
9. **Event and telemetry profiles.** Pin CloudEvents 1.0.2, OpenTelemetry specification 1.60.0, and semantic conventions 1.44.0 plus the stability of each adopted namespace. Carry references and bounded transition metadata only; prohibit raw context, evidence, prompts, credentials, tokens, purpose text, and stable cross-purpose person identifiers.

### P2 - informative tracking, not release dependencies

10. **Workload and agent identity.** SPIFFE 1.15.2 can inform deployed workload identity. WIMSE architecture -08 and the AI-agent applicability -02 draft can inform role separation, but neither should be a normative dependency. Identity evidence authenticates a workload under a binding; it does not establish the human principal, context subject, disclosure authority, or external-action authority.
11. **NIST agent work.** Track the NIST AI Agent Standards Initiative and NCCoE concept paper, but describe both accurately: the initiative is not a technical standard and the NCCoE paper is a draft concept.
12. **AI Act traceability.** Use the AI Act only as legal/governance design input. Read Regulation (EU) 2024/1689 together with the in-force 2026/1744 amendment until EUR-Lex publishes a visibly updated consolidated text. OCP conformance is never a legal-compliance claim.

## 3. Current source/version caveats

| Work | Current source pin | Caveat for OCP 0.4 |
|---|---|---|
| PAM | v1.0, Published, 2026-02-17 | Independent project rather than SDO standard. Official provider mappings are described as best-effort, native provider support was not asserted, and the official Python tooling page lists signature tools as planned. Its generic “system prompt injection” import strategy is incompatible with OCP's untrusted-data boundary. |
| OAuth base/security | RFC 6749 plus RFC 9700/BCP 240 | Do not cite OAuth 2.1 as a finished standard. Use the published base and current security BCP with exact applicable updates. |
| OAuth metadata | RFC 8414 and RFC 9728 | Authorization-server metadata and protected-resource metadata are distinct documents and roles. Discovery does not authorize access. |
| RAR | RFC 9396 | `authorization_details` supplies a carrier, not OCP comparison semantics. OCP must define typed equality/containment and partial approval. |
| DPoP | RFC 9449 | Sender-constrains tokens; it does not prevent copying or misuse of context after authorized plaintext delivery. |
| MCP | dated specification 2026-07-28 | Fast-moving protocol. Bindings must pin the date and cannot assume future version compatibility. MCP context/resources/tools/tasks do not define OCP acceptance. |
| A2A | latest spec page says 1.0.0; negotiated protocol 1.0 | The official repository release page is timestamped 2026-05-28 and its embedded 1.0.1 changelog is dated 2026-05-26. Record the implementation patch and negotiated protocol version separately. A2A task state is not OCP review state. |
| PROV-O | W3C Recommendation, 2013-04-30 | Mature provenance model, but it has no native OCP scoped-acceptance or grant-receipt semantics. |
| C2PA | technical specification 2.4 | Released industry specification. Its own model avoids declaring provenance “good” or “bad”; OCP must not turn validation into truth or rights. |
| VC / Data Integrity | W3C Recommendations dated 2025-05-15 | Stable data/proof models, but cryptosuite and status choices still belong to a concrete credential profile. |
| SD-JWT | RFC 9901, Proposed Standard, 2025-11 | Published RFC, not an Internet-Draft. Selective disclosure does not by itself supply OCP purpose enforcement or acceptance. |
| JSON Schema | Draft 2020-12 current corrected documents | Some older 2020-12 documents are marked obsolete in favor of corrected text without functional/meta-schema change. Pin the current official URIs/catalog. |
| JCS / I-JSON | RFC 8785 Informational; RFC 7493 Proposed Standard | JCS requires I-JSON constraints and ECMAScript-compatible number serialization. Generic sorted-key JSON is not sufficient. |
| Problem Details | RFC 9457 | Current RFC and replacement for RFC 7807. OCP error codes/details still require privacy and stability rules. |
| CloudEvents | 1.0.2 stable release | Envelope only; not state, audit, authorization, or acceptance. |
| OpenTelemetry | spec 1.60.0; semantic conventions 1.44.0 | Core and semantic-convention releases are independent. Individual semantic areas have different stability; pin adopted attributes, not just the top-level release. |
| SPIFFE | rendered docs report 1.15.2 latest | Specification family with component-specific stability. Appropriate for workload identity, not for collapsing workload, agent, model, publisher, client, human, and subject roles. |
| WIMSE architecture | draft-ietf-wimse-arch-08, 2026-07-06, expires 2027-01-07 | Active working-group Internet-Draft intended Informational, not an RFC. It may change or expire. |
| WIMSE AI-agent applicability | draft-ni-wimse-ai-agent-identity-02, 2026-02-28, expires 2026-09-01 | Individual draft with no formal IETF standards standing and near expiry on the snapshot date. Recheck or remove the pin immediately before OCP publication. |
| CRP core | draft-vidiniotis-crp-core-00, 2026-05-24, expires 2026-11-25 | Active individual Internet-Draft, not IETF-endorsed. Its gateway assembles and injects context and enforces runtime safety; it does not define OCP acceptance, grant, proposal/review, disclosure, or no-action-authority semantics. Monitor only; do not make it a core dependency. |
| NIST agent initiative | created 2026-02-17, updated 2026-04-20 | Initiative and convening activity, not a conformance standard. |
| NCCoE agent identity | draft concept paper, 2026-02-05 | Problem framing only; not a normative identity/authorization protocol. |
| EU AI Act | Regulation (EU) 2024/1689 plus amending Regulation (EU) 2026/1744 | The amendment was published 2026-07-24 and is in force. The EUR-Lex consolidated base-act view did not visibly incorporate it at access time, so cite/read both and recheck consolidation. |

## 4. Required semantic separations in every mapping

| Do not collapse | Required distinction |
|---|---|
| provenance ↔ truth | A source, PROV graph, C2PA manifest, PAM provenance block, or valid signature identifies claims/origin under its model; it does not prove the underlying statement true. |
| identity ↔ authority | SPIFFE/WIMSE/OIDC/DID/VC identity evidence does not itself authorize OCP disclosure, accepted-state changes, or external actions. |
| authentication ↔ authorization | An authenticated transport peer or signed artifact still needs current operation-time authorization and OCP containment checks. |
| grant receipt ↔ token/capability | The OCP receipt records effective semantics; it is non-secret and must never become a bearer credential. |
| context ↔ instruction | PAM instructions, MCP content, A2A parts, imported conversations, artifacts, and OCP entries are untrusted data unless a separate policy channel explicitly defines behavior. |
| active/current ↔ accepted | PAM lifecycle, A2A task state, MCP task state, credential status, and provider confidence do not equal an OCP review decision for an exact revision and scope. |
| event/telemetry ↔ authoritative state | CloudEvents and OpenTelemetry carry notifications/measurements, not the governed record of acceptance or authorization. |
| signature validity ↔ legal/subject consent | Key verification does not prove lawful collection, subject authority, rights, consent, or continuing status. |
| sender constraint ↔ downstream control | DPoP/mTLS reduce credential replay; they do not control authorized plaintext after delivery. |
| conformance ↔ legal compliance | OCP artifacts may support evidence and controls but cannot establish GDPR, Data Act, AI Act, accessibility, or other compliance. |

## 5. Mapping deliverables to include in the release tree

Recommended release artifacts, each with exact source pins:

- `mappings/PAM-v1.0.md` plus a future machine-readable field map, loss-report schema, and fixtures;
- a future `bindings/oauth-rar/` package covering RFC 6749, RFC 9700, RFC 8414, RFC 9396, RFC 9728, RFC 8707, and optional RFC 9449;
- a future `mappings/prov-o.md`;
- a future `mappings/c2pa-2.4.md` under the artifact profile;
- a future `profiles/credential/` mapping VC 2.0, Data Integrity 1.0, and SD-JWT RFC 9901;
- a future `bindings/mcp-2026-07-28/`;
- a future `bindings/a2a-1.0/` with implementation patch metadata;
- a future `bindings/events-cloudevents-1.0.2/`;
- a future `mappings/opentelemetry-1.60-semconv-1.44.md`;
- informative `research/agent-identity-snapshot-2026-08-12.md` for SPIFFE/WIMSE/NIST, excluded from normative dependencies;
- a legal-source note that pins both EU regulations and disclaims legal-compliance inference.

Each normative mapping must state direction, supported objects and fields, cardinality, lifecycle mapping, identity/proof/authorization boundaries, loss behavior, negative fixtures, and round-trip acceptance criteria.

## 6. Validation performed

- `registries/standards.json` parses as JSON, contains 30 unique stable IDs, and every entry has `title`, `version`, `status`, `date`, `url`, `accessed_date`, `maturity`, and `role`.
- A live redirect-following HTTP check on 2026-08-12 returned HTTP 200 for 28 of the original 29 registry URLs. CRP was subsequently verified through the official IETF Datatracker; the automated NCCoE exception remains as described below.
- The NCCoE concept-paper URL returned HTTP 403 to command-line `curl`, but the official page was accessible through browser retrieval and showed the title, publication date 2026-02-05, and status Draft. This appears to be automated-client blocking rather than evidence of a broken URL.
- Version claims for PAM, MCP, A2A, C2PA, OpenTelemetry, SPIFFE, WIMSE, NIST, and the EU amendment were checked against their official publisher pages. RFC status/version claims use RFC Editor pages.

## 7. Recheck gates immediately before publication

1. Re-open MCP and A2A version pages; do not advance a pin without updating fixtures.
2. Re-open OpenTelemetry core and semantic-conventions pages and record per-attribute stability.
3. Re-open WIMSE architecture and AI-agent drafts. The individual AI-agent draft expires 2026-09-01 unless replaced.
4. Check whether EUR-Lex has published a consolidated Regulation (EU) 2024/1689 incorporating 2026/1744; if not, keep the two-document citation.
5. Check PAM changelog/schema and official SDK capability pages; do not assume 1.0-compatible behavior from later site changes.
6. Re-run link, JSON, schema, fixture, and cross-reference validation and record the exact access date in the release manifest.
