Adoption records

PDPP Core

Status: normative where cited. Document version 1.0-draft-1.

Version pinned

PDPP Core v0.1.0, spec-core.md in PDP-Connect/pdpp at commit 8f79a48d7fe94a6b2aab15aac78d409b9ea13712 (committed 23 September 2026; main on 4 October 2026). The document's header reads "Personal Data Portability Protocol (PDPP) v0.1.0", status "Normative draft", dated 3 September 2026. Its SHA-256 and size, and those of the other PDPP files cited here, are recorded in pdpp.lock.json.

Also read at the same commit, and cited only for the facts stated below: spec-collection-profile.md (status "Informative. Builder guidance for connector collection. Not a conformance requirement."), GOVERNANCE.md (status "Consultation draft") and README.md. The reference implementation is no longer in this repository: the README at commit 8f79a48 says it lives in PDP-Connect/data-connect under reference-implementation/, read at data-connect commit 832c7985b2338b3cd0a10da9546e517eac439d75.

Licences, from the repository at commit 8f79a48: code Apache-2.0 (LICENSE), specification text Community Specification License 1.0 (LICENSE-specs; the REUSE.toml override uses LicenseRef-CSL-1.0), documentation CC BY 4.0 (LICENSE-docs).

pnpm check:pdpp-pin fails if a file in spec/adoption/ or spec/bindings/ cites PDPP without this commit, links another PDPP commit or states another PDPP Core version. A weekly workflow runs pnpm check:pdpp-pin --upstream, which fails if the pinned text no longer matches the lock and flags any cited file whose text on upstream main has changed.

What is taken

• Grants (PDPP Core v0.1.0 section 7): the immutable grant artefact and its fields version, grant_id, issued_at, subject, client, source, source_declaration, purpose_code, purpose_description, access_mode, streams (StreamGrant: name, instance_ids, fields, time_constraint, resources), selection_preset, retention and expires_at. Lifecycle (active, expired, revoked) is tracked by the authorisation server, not stored in the grant.
• Selection requests (section 6), carried in an RFC 9396 authorization_details envelope of type https://pdpp.dev/data-access, with purposes as absolute URIs.
• Sources, records and the query surface (sections 4, 5 and 8), including source declarations and their streams.
• Introspection (section 8): active, pdpp_token_kind, subject_id, grant_id, client_id, exp and authorization_details, with the rule that the response contains everything needed to enforce the request.
• Errors (section 8): the error object on the PDPP endpoints, with PDPP's codes where PDPP defines one, such as not_found, invalid_request, grant_revoked, grant_expired and blob_not_found (B1.9). The error registry lists these codes without registering them.
• Token kinds (section 10): owner and client tokens, distinguished by pdpp_token_kind; section 8 lets companion profiles add kinds and requires unknown kinds to be treated as unauthorised.
• Conformance requirements (section 9): the numbered requirements for the Authorization Server and Resource Server roles. Section 9 says a formal conformance test suite "is planned but is not defined in v0.1", and GOVERNANCE.md section 5.7 says it is published by 1 January 2027 and that Verified Operator opens on its publication. Until then Autonym builds its own checks from the section 9 requirements.

Why

PDPP is a neutral grant model hosted under LF Decentralized Trust, with a published governance process and a planned conformance programme. Building the grant layer to its contract is cheaper than defending a bespoke grant protocol, lets recipients that already speak PDPP read Open Personal Context records, and opens the Verified Operator route when it exists. PDPP is the first authorisation binding, and the Autonym reference server implements it natively.

What is extended

PDPP Core section 11 leaves interoperable audit and transparency events to "a separate companion profile", and section 10 says revocation is not deletion. Open Personal Context adds, through B1:

• disclosure levels and approved renderings, expressed as statically declared derived streams. PDPP Core mentions derived streams only in non-normative text (section 12), so this mapping is Open Personal Context's, not PDPP's;
• per-read signed receipts and the owner's log (A9);
• purge instructions and acknowledgement (A10);
• typed context with provenance, validity and temporal selection (A4);
• pairwise subject handles (A3), which PDPP does not define: its subject.id is an opaque string;
• mandatory PKCE and DPoP (A6.3). PDPP is "a profile of OAuth 2.0", mentions PKCE only in passing and describes DPoP as non-normative advice and a candidate hardening profile for a later version.

What is replaced or not used

• The Collection Profile and connector runtime are not used: they are informative in PDPP, and continuous connectors are reserved for Open Personal Context 2.0.
• PDPP's six example purpose URIs under pdpp.dev are not adopted as the purpose vocabulary. B1 uses urn:autonym:purpose:<category> for the ten Open Personal Context purposes, annotated with W3C Data Privacy Vocabulary terms (see the DPV record).
• PDPP owner tokens are not issued, so owner-authenticated delete and self-export are not offered through PDPP (B1, B1-D8).
• Bearer client tokens are not accepted for any client: every token is DPoP-bound (A6.3, B1-D4).

Deviations

At commit 8f79a48 there is no conformance suite yet, DPoP is non-normative advice rather than an optional feature, and the reference implementation lives in PDP-Connect/data-connect rather than in the PDPP repository. This record states those verified facts.

The places where the binding departs from a strict reading of PDPP Core v0.1.0 are listed as B1-D1 to B1-D8 in B1.11. None widens what a PDPP grant authorises.

Conformance checks

CONSENT-01, CORE-01, DELEGATE-01 and BINDING-01 in the conformance manifest, with runtime evidence pending as the manifest records. BINDING-01, the check of the optional pdpp-binding feature, tests the binding's own choices: the generated source declaration, static streams and the owner endpoints of B1-D8. Autonym's PDPP Core checks will cite PDPP Core v0.1.0 section 9 by role and item number, never by invented identifiers, and are replaced by PDPP's suite when it is published.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.