For an integrator reading both specifications side by side. KYA-OS / Checkpoint defines org.kya-os/response-proof, a signed ProofMeta object an MCP server can attach to a tool-call response to attest agent identity and session context. OpenChainGraph is a compute-identity and artifact-provenance standard, a different problem. This note states plainly where the two overlap at the primitive level (same signature family, same canonicalization) and where they do not (KYA-OS's required fields include session/handshake concepts OCG has no infrastructure for). It corrects an earlier internal review that scored more of the overlap as absent than the specification text actually supports.
org.kya-os/response-proof emitter. The KYA-OS ProofMeta object is schema-closed (additionalProperties:false) with seven required fields. Three of them, nonce, audience, sessionId, are session/handshake concepts bound to KYA-OS's own protocol exchange, and OCG has no equivalent infrastructure to populate them truthfully. A partial object does not validate against that schema. No reader should present an OCG artifact, or anything built from this note, to a KYA-OS verifier as a conformant proof.ProofMeta needs for the fields it can populate:| ProofMeta field | Sourceable from OCG? | Basis |
|---|---|---|
| did | SOURCEABLE, conditionally | SPEC.md §9 defines did:key as the recommended verificationMethod/keyid, already used for signatures[].keyid (§9) and for audit_signature.proof.verificationMethod (§16, Proof Binding). §16.4 names the server-signing case this export needs: a stable institutional issuer anchoring to did:web over the publisher's domain, key in HSM/KMS, signing server-side via the §12 compute path. That is a documented, already-specified pattern, not new infrastructure. Condition: only present when §16 Proof Binding is populated on the artifact, which is rare today (1 verificationMethod hit across the current graph, re-derived at publication time; most artifacts still lack it). |
| kid | SOURCEABLE, same condition as did | KYA-OS requires kid match the JWS protected header and resolve under the signer's key material. A did:key fragment (did:key:z6Mk...#z6Mk...) or the §16 verificationMethod value satisfies that structurally. |
| ts | SOURCEABLE | Trivial, computable at serve time. |
| requestHash | SOURCEABLE | Computable at serve time from the request. |
| responseHash | SOURCEABLE | Computable at serve time from the response; conditional on outcome per KYA-OS's own schema. |
| audience | NOT SOURCEABLE as an artifact-derived value | Caller-supplied at export time would be the truthful route, not artifact sourcing. The worker has no authenticated caller identity today (no session/OAuth layer on MCP calls per current architecture), so filling this field would be the responder's own guess at a recipient, which is invented, not sourced. If the worker later gains authenticated MCP sessions, this becomes sourceable; today it is not. |
| sessionId | NOT SOURCEABLE | No session concept exists at all, caller-supplied or otherwise. Genuinely absent infrastructure, not a documentation gap. |
| nonce | NOT SOURCEABLE, as specified | A self-minted per-call random value satisfies the JSON Schema string type but not KYA-OS's replay-prevention semantics, which are bound to the _kyaos handshake. Filling it would be schema-legal and protocol-dishonest. |
did and kid are sourceable via a primitive OCG already ships and already uses elsewhere in the specification (§9 did:key, §16.4 did:web for server-side institutional signing). The gap that actually blocks a conformant org.kya-os/response-proof emitter is narrower than first scored, three required fields, not five, but it is still fatal to schema conformance: additionalProperties:false with three required keys structurally absent cannot validate as a partial object. Narrowing the gap does not close it.org.kya-os/response-proof emitter becomes possible only if the worker gains an authenticated MCP session layer that can genuinely populate audience, sessionId, and nonce per KYA-OS's handshake semantics. That is a separate, materially larger design decision, a session/authentication layer for the MCP worker, and is not recommended here as a prerequisite to chase. Until it exists, this note is the full extent of the interop story: a primitive overlap worth knowing about, not a bridge.