# PHC references These primary references inform the proposal and its experimental utilities. References do not imply endorsement, conformance or a license to unrelated material. Living specifications and provider documentation require an exact version review before implementation. ## S01 MCP - [Model Context Protocol specification](https://modelcontextprotocol.io/specification/latest). - [MCP authorization, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). MCP supplies tool and resource transport mechanisms. A PHC integration must identify and test its exact supported protocol edition; transport support alone does not establish context semantics or custody. ## S02 OAuth security - [RFC 9700 / BCP 240](https://www.rfc-editor.org/rfc/rfc9700.html), *Best Current Practice for OAuth 2.0 Security*. OAuth deployment guidance informs the authorization boundary. PHC additionally requires current policy over context and verified identity mapping. The kit does not implement an OAuth service. ## S03 Identity and discovery - [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html). - [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html), *OAuth 2.0 Protected Resource Metadata*. Authentication and resource discovery remain separate from grants over records. Matching display names or email addresses cannot establish an account binding. ## S04 Stronger authorization profiles - [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html). - [RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html), *OAuth 2.0 Demonstrating Proof of Possession (DPoP)*. PHC does not claim FAPI certification or assume every client supports sender-constrained authorization. A broker's protection covers only the hop to which it is bound. ## S05 Detailed authorization requests - [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396.html), *OAuth 2.0 Rich Authorization Requests*. A PHC authorization-details vocabulary would need agreed semantics and a binding. No such type is registered by this draft. ## S06 JOSE and algorithm update - [RFC 8037](https://www.rfc-editor.org/info/rfc8037/). - [RFC 9864](https://www.rfc-editor.org/rfc/rfc9864.html), *Fully-Specified Algorithms for JOSE and COSE*. An exchange binding must resolve algorithm identifiers, key types, canonical bytes and test vectors together. This review does not change upstream DEC identifiers or signed artifacts. ## S07 Canonicalization - [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785.html), *JSON Canonicalization Scheme (JCS)*. The experimental utilities implement bounded canonicalization checks. Independent cross-language interoperability and a complete cryptographic exchange profile remain separate work. ## S08 Encrypted exchange - [RFC 7516](https://www.rfc-editor.org/rfc/rfc7516.html), *JSON Web Encryption (JWE)*. JWE supplies an encrypted-object framework. The kit does not implement encrypted PHC exchange, recipient-key resolution or a service replay ledger. ## S09 Agent2Agent - [A2A specification](https://a2a-protocol.org/latest/specification/). A2A is relevant to task delegation. It does not replace context custody or grants, and no A2A adapter is qualified by this draft. ## S10 Provider integration references - [OpenAI MCP/connectors guide](https://developers.openai.com/api/docs/guides/tools-connectors-mcp). - [Claude MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector). - [Gemini Interactions overview](https://ai.google.dev/gemini-api/docs/interactions-overview). An implementer must verify the exact API, model, client, retention terms and transport configuration used. Developer API support does not establish support in a provider's consumer application. These links are implementation references, not executed PHC integration results. ## S11 Deployment independence PHC does not require a cloud vendor or database product. Any claimed recovery or custody profile needs evidence for the implementation's actual storage, key, disclosure and recovery boundaries. ## S12 Provenance - [W3C PROV-DM](https://www.w3.org/TR/prov-dm/), *The PROV Data Model*. PROV's entities, activities and agents provide a useful conceptual mapping for attributed derivations. PHC does not claim PROV conformance or require RDF. Provenance is not authorization. ## S13 Emerging memory work - [Portable Agent Memory, version 1](https://arxiv.org/html/2605.11032v1). - [A Secure Agent Memory Exchange Protocol, version 1](https://arxiv.org/html/2507.10562v1). These papers provide related proposals. Their authors' claims are not PHC results; SAMEP's evaluation describes performance projections. Neither system was executed as part of this kit. Any comparison requires independently measured semantic round trips and failure behavior. ## S14 DEC and upstream attribution - [Azimuth agent-dec, pinned commit](https://github.com/azimuth-ink/agent-dec/tree/1b94ef83f61a3f07b87ea72d80f330e2d836916a). - [Pinned DEC certificate format](https://github.com/azimuth-ink/agent-dec/blob/1b94ef83f61a3f07b87ea72d80f330e2d836916a/spec/01-certificate-format.md). - [Pinned upstream license](https://github.com/azimuth-ink/agent-dec/blob/1b94ef83f61a3f07b87ea72d80f330e2d836916a/LICENSE). The kit includes the pinned DEC schema, signed public run and step fixtures, public key, license and digest manifest. The independently written Node adapter checks their original signatures and digest chain. It does not execute the upstream Python verifier, replay the run or assess attestations. See [DCER integration](DCER.md). ## S15 Experimental grammar and verification - [JSON Schema 2020-12](https://json-schema.org/draft/2020-12). - [Experimental PHC binding](BINDING.md). - [Local verification record](../evidence/verification.json). The schema evaluator supports the keywords used by the checked-in schemas; it is not a general-purpose JSON Schema implementation. Local test evidence is distinct from independent interoperability, external security review and the planned end-to-end conformance cases.