Standards adoption register
spec 1.0-draft-1
Status: normative where cited. Document version 1.0-draft-1. Generated from the records in this folder by pnpm spec:adoption; do not edit by hand.
Every external standard the specification uses has one adoption record here, with the same headings: version pinned, what is taken, why, what is extended, what is replaced or not used, deviations, and the conformance checks that prove the integration. The specification cites the record wherever it uses the standard. An adopted standard is pinned; a later version is taken only through a change entry with a migration note.
| Standard | Version pinned | Status | What Open Personal Context takes | Why | What it extends or replaces | Specification home |
|---|---|---|---|---|---|---|
| W3C AI Agent Memory Interoperability CG and draft-saihm | Community Group charter 1.0 (adopted 19 June 2026); draft-saihm-memory-protocol-01 (27 May 2026) | Track and align shapes | Nothing normative; receipt and erasure message shapes are compared for alignment | Avoids gratuitous divergence from emerging agent-memory work | Open Personal Context receipts are per read, not per memory write | A9, A10 notes |
| W3C Data Privacy Vocabulary (DPV) | DPV 2.3 (25 February 2026) | Adopt terms | Purpose and provenance classes | Interoperable purpose names rather than invented ones | Maps Open Personal Context purposes to DPV terms; adds the advertising constraints | A4.2, A6.2 |
| Human Context Protocol | Position paper SSRN 5403981 (project page dated 18 December 2025); no protocol version or file format published | Map, do not adopt | Nothing yet; a mapping from user-held preferences into the declared lane is planned | Lets people who keep preferences in an HCP server bring them into a record as declared entries | Replaces language-model-mediated disclosure with deterministic, person-approved renderings | A11 import mapping (planned) |
| IAB Tech Lab Data Deletion Request Framework | Version 2.0 (August 2026) | Adopt the request and acknowledgement shape | Signed deletion request and acknowledgement concepts | A published shape for purge semantics that recipients may already handle | Binds the request and acknowledgement to the grant and receipt identifiers | A10 |
| ISO/IEC 24751 (AccessForAll) | ISO/IEC 24751-2:2008 (with parts 1 and 3:2008 and part 4:2023) | Adopt the vocabulary for the accessibility domain (catalogue entry only) | Accessibility preference terms, pending a licensed text | Avoids inventing accessibility keys | Maps to vocabulary keys | Vocabulary registry |
| ISO/IEC TS 27560 consent record information structure | ISO/IEC TS 27560:2023, edition 1 (8 August 2023) | Adopt the record structure (catalogue entry only) | Consent receipt fields, pending a licensed text | Lets a grant be exported as a recognised consent record | Adds disclosure level and rendering version | A6.3, A9, A11 |
| JWS (RFC 7515), JCS (RFC 8785), JWK (RFC 7517), JWK thumbprints (RFC 7638), JWA (RFC 7518), I-JSON (RFC 7493), JWK exp (OpenID Federation 1.0) | RFC 7515, RFC 7517 and RFC 7518 (May 2015); RFC 7493 (March 2015); RFC 7638 (September 2015); RFC 8785 (June 2020); RFC 9864 (October 2025); OpenID Federation 1.0, Final (17 February 2026), JWK exp only | Adopt | Signing receipts, disclosures, purge instructions, purge acknowledgements and exports over canonical JSON, with ES256 and published keys named by their thumbprints and retired with exp | Standard signatures with maintained libraries; no bespoke cryptography | Defines the receipt, disclosure, purge and export object shapes and their protected typ values, the provider key set and one spelling for instants | A5.3, A5.4, A9, A10, A11, A15.2 |
| JSON Schema 2020-12, OpenAPI 3.1, RFC 9457 Problem Details | JSON Schema 2020-12 (16 June 2022); OpenAPI 3.1.0 (15 February 2021); RFC 9457 (July 2023) | Adopt | Wire shapes, API description and the error format | The generated artefacts and their drift checks depend on them | Adds the closed registry of urn:autonym:error:* types | A8, B4, generated contracts |
| JWE (RFC 7516) and Argon2id (RFC 9106) | RFC 7516 (May 2015); RFC 9106 (September 2021) | Adopt | Passphrase-encrypted export | Standard envelope encryption for the portable export, with a maintained memory-hard key derivation | None | A11.2 |
| W3C Linked Web Storage / Solid | Linked Web Storage Protocol 1.0, Working Draft of 21 September 2026; Solid Protocol 0.11.0 (12 May 2024) | Optional storage binding, 2.0 stream | Resource addressing and access grants as an alternative store | Lets a person keep the record in a pod they already have | Binding only; the native store remains the default | Binding B2 (post 1.0) |
| Model Context Protocol | Specification revision 2026-07-28 (current revision on 4 October 2026) | Adopt as the agent binding | Tools, resources, prompts, server discovery, the stateless Streamable HTTP transport and the MCP authorisation flow | The surface assistants actually use | Defines the Open Personal Context tool set, confirmation semantics and briefing resources; no generic record access | A7, B3 |
| OAuth 2.1, PKCE, RFC 9396 rich authorisation requests, DPoP (RFC 9449) | draft-ietf-oauth-v2-1-16 (3 September 2026) with RFC 6749, 6750, 7009, 7523, 7591, 7636, 7662, 8252, 8414, 8693, 8707, 9068, 9101, 9126, 9207, 9396, 9449, 9700 and 9728, OpenID Connect Core 1.0 section 9 and draft-ietf-oauth-client-id-metadata-document-02 | Adopt as the authorisation primitives of A6, B1, B3 and B4 | Client registration and lifecycle, PKCE flows, pushed authorisation requests, resource indicators, sender-constrained tokens, structured authorisation details, protected-resource and server metadata, issuer identification, revocation, token exchange and JWT access tokens | Mature, library-supported primitives that recipients already speak | Profiles the authorization_details type for domain and level, the contribution request and the grant-offer exchange; makes PKCE S256 and DPoP mandatory for every client and every access token; nothing replaced | A6, B1 |
| PDPP Core (PDP-Connect, LF Decentralized Trust) | PDPP Core v0.1.0 at commit 8f79a48 (2026-09-23) | Adopt as the normative 1.0 grant binding (B1); implement in the Autonym server | Grants with purpose, selection, expiry and revocation; sources and records; the query surface; introspection; the Core section 9 conformance requirements, tested by Autonym's own checks until PDPP publishes its suite | A neutral, foundation-hosted grant protocol with a planned conformance programme; building on it is cheaper than defending a bespoke one and opens the Verified Operator route | Adds disclosure levels and renderings as statically declared derived streams; adds per-read receipts, purge acknowledgement and typed context, which Core leaves out; makes DPoP and PKCE mandatory where Core leaves them out or advisory | B1 |
| SD-JWT VC, OpenID4VC, SMART Health Links, International Patient Summary | RFC 9901; draft-ietf-oauth-sd-jwt-vc-19; OpenID4VP 1.0; OpenID4VCI 1.0; SMART Health Cards and Links IG 1.0.0; IPS IG 2.0.1 | Reserved | Nothing in 1.0; credential presentations and an emergency card in 2.0 | Needed only by capabilities reserved for 2.0 | Nothing in 1.0 | Reserved chapters (A12, A13) |
| SCITT architecture and COSE Receipts | RFC 9943 and RFC 9942 (June 2026) | Evaluate; adopt if the receipt format can be expressed as a SCITT receipt | Under evaluation - transparency receipts and the append-only log shape | Aligns the accountability log with a published transparency standard | Possible replacement of the bespoke chain format; not yet decided | A9, this record decides |
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.