PDPP participation
-Participate
-Ask a question about the draft, or propose a change to the protocol.
-- {built.unavailable} {built.unavailableHref && {built.unavailableLinkLabel}} -
- )} -PDPP participation
-Ask a question about the draft, or propose a change to the protocol.
-The Personal Data Portability Protocol
-Lets personal data move freely, with consent. Decide what an app can see, for what, and for how long.
- -One button, everything the platform holds, for as long as the app wants. Nothing records what you agreed to, and turning it off means finding a settings page on someone else's site.
-Two fields, one purpose, three months, until a date you chose. It is recorded where you and the app can both see it, every request is checked against it, and ending it is one click. Ask for a third field, or a date outside the range, and the request is refused.
-[ 247 ] signatories since 3 September
-| Signatory | -Type | -Country | -Version | -Signed | -
|---|---|---|---|---|
| [ Organisation name ] | Implementer | Netherlands | 1.0 | 2026-09-05 |
| [ Organisation name ] | Research institute | Germany | 1.0 | 2026-09-04 |
| [ First name L. ] | Individual | Australia | 1.0 | 2026-09-04 |
| [ Organisation name ] | Civil society | United Kingdom | 1.0 | 2026-09-03 |
| [ First name L. ] | Individual | United States | 1.0 | 2026-09-03 |
One specification, a reference server you can run today, and three roles to build for. Pick yours.
- -PDPP Principles · v1.0 · Published 3 September 2026
-When an individual permits a service to use information held about them by another, the permission is commonly granted in general terms and recorded nowhere the individual can examine.
-The choice is often between all of the information and none of it, and once given, the permission is rarely visible, rarely verifiable, and rarely reversible in practice. The party relying on the information carries the same uncertainty, since it holds no reliable record of what was consented to, for what purpose, or by whom. As more of daily life is mediated by systems that act on personal information, and as artificial intelligence increases what can be done with it, the absence of a specific, durable and enforceable account of what has been agreed has become a matter of general concern.
-Anyone. Individuals, companies, universities, civil society groups, and public bodies are all welcome. Individuals appear as first name and last initial; organisations by name. Your email is never shown.
-Individuals sign for themselves rather than their employer. Signing is not a commitment to build anything or a sign-off on every line of the specification, and you can withdraw by email at any time.
-{{ privacyNote }}
-We email you to confirm. Organisations sign from an address at their own domain.
-[ 247 ] signatories since 3 September
-| Signatory | -Type | -Country | -Version | -Signed | -
|---|---|---|---|---|
| [ Organisation name ] | Implementer | Netherlands | 1.0 | 2026-09-05 |
| [ Organisation name ] | Research institute | Germany | 1.0 | 2026-09-04 |
| [ First name L. ] | Individual | Australia | 1.0 | 2026-09-04 |
| [ Organisation name ] | Civil society | United Kingdom | 1.0 | 2026-09-03 |
| [ First name L. ] | Individual | United States | 1.0 | 2026-09-03 |
| [ Organisation name ] | Platform | United States | 1.0 | 2026-09-03 |
/principles/supporters.json
-Specification · v0.1.0 · Normative draft, 2026-08-14
-The specification defines three things: what an app may ask for, what the user approved, and how the server enforces the difference.
-It is built on OAuth 2.0 and RFC 9396.
-Machine readable at /llms.txt and /specification/index.json · purpose codes resolve under /purpose/
A grant is the immutable record of what the user approved. It is issued by the authorization server after the user has acted on a selection request, and it is the only artifact a resource server consults when deciding whether to answer a query.
-A grant MUST NOT be modified after issuance. Where the user wishes to change what an accessor may see, the authorization server MUST issue a new grant, and MUST NOT narrow or widen an existing one.
-A grant MUST record the source declaration snapshot against which it was issued. A resource server MUST evaluate every request against that snapshot, not against the current declaration.
-Where access_mode is single_use, the resource server MUST refuse any request made after the first successful retrieval. Where it is continuous, the resource server MUST answer requests until the grant expires or is revoked, and SHOULD support incremental sync as described in §4.
A grant is represented as a JSON object. The example below is non-normative.
-// non-normative example -{ - "grant_id": "grn_8f2c1a04", - "client_id": "https://habitcoach.example/app", - "source": { "id": "https://sleeptracker.example", "official": true }, - "purpose": "https://pdpp.dev/purpose/personalisation", - "access_mode": "continuous", - "streams": [ - { - "stream": "sleep_sessions", - "fields": ["sleep_score", "duration_min"], - "range": { "from": "2026-06-01", "to": "2026-09-01" } - } - ], - "declaration_snapshot": "sha256:4c1f...9ab2", - "retention": { "max_days": 90, "on_expiry": "delete" }, - "issued_at": "2026-09-02T09:14:00Z", - "expires_at": "2026-12-01T00:00:00Z" -}-
| Field | -Required | -Description | -
|---|---|---|
grant_id | Yes | Stable identifier, unique to the authorization server |
purpose | Yes | A URI from the purpose registry in Appendix A |
access_mode | Yes | single_use or continuous |
declaration_snapshot | Yes | Digest of the source declaration the grant was issued against |
retention | Yes | Maximum retention and the action on expiry |
expires_at | No | Absent means the grant runs until revoked |
Governance · Consultation draft · Revised 2 September 2026
-Two parts. Part A is how it runs from 15 October. Part B is how we propose it runs once there is an elected committee. Both are open for comment until 1 October: how to comment.
-The specification and Part A are frozen while people comment, the Principles are published, and you can sign now. This stage ends on 15 October.
-The maintainers run things. Supporters can sign, but nobody can be verified until the review committee is named.
-Five people, at least three with no connection to Vana or Open Data Labs, chosen on published criteria and not removable by the maintainers. They review every application for verified status in public and give a decision with reasons, which the maintainers act on. Verification opens at this point.
-Partners elect a five-seat steering committee, one organisation one vote, with the Chair elected directly. The steering committee is the only body that can change the specification or grant a status, and it does both by majority vote. It appoints a technical committee, which reviews every application and every proposed change in public and recommends. The Chair records the vote and merges. This starts at 100 Partners or on 15 October 2027, whichever comes first, and not before 15 April 2027. Full detail is in Part B of the governance document.
-Before the steering committee exists, the interim technical committee recommends and the maintainers merge on that recommendation with no discretion. The shape is the same; only the body that votes is missing.
-Everything you need to build on PDPP is here: the specification, a reference server you can run today, and guidance for the parts people tend to get stuck on.
- -You have data, on a platform or in a connector, and you want apps to be able to ask for it with consent. You need to write a source declaration that validates against Core §5, then serve records through a Core §8 resource server.
-Start with Core §4 and §5, then the declaration schema and the validator.
- Core §5 → -You are building an app or agent that needs someone's data. You ask for exactly what you need with a Core §6 selection request, receive a grant, and query within it. If you have done OAuth, this is OAuth with a stricter scope.
-Start with Core §6 and §7, then the client example in the reference implementation.
- Core §6 → -You run the authorization server, the resource server, or both. Yours is the code that records the grant and refuses anything outside it. Core §8 is your interface contract and §9 is what the test suite will check.
-Start by running the reference implementation, then read Core §8 against it.
- Deploy the reference server → -A complete authorization and resource server with scoped access, revocation, and an MCP endpoint so you can point an assistant at it and watch grants get enforced. Use it to see the protocol behave before you write your own.
- Deploy guide → -DataConnect ships signed connectors for both. Install it, grant an app one stream for one week, then revoke it, and you have seen the whole protocol.
- DataConnect releases → -The Collection Profile is one worked approach to collection, scheduling and refresh for connector-backed sources. Use it if you do not already have a pipeline. If you do, you conform as long as your declaration validates and your server answers §8 queries.
- Collection Profile → -Discovery and Trust walks through locating a provider-native declaration under RFC 9728 and what to check before accepting it. The requirements themselves are in Core §5, Declaration acceptance, and this document is the how-to.
- Discovery and Trust → -Every grant names a purpose from the registry. Most requests fit an existing code, and ai_training is the one that triggers a protocol-level consent step. If nothing fits you can propose one, and proposals are considered on a published cycle.
Extension profiles add lexical search, aggregation and semantic query on top of Core without changing what Core means. Check whether one already covers your case before writing your own; an extension that weakens Core semantics is rejected.
- Extension profiles → -Follow the work, sign the Principles, or build something and get it verified. All of it is voluntary, and none of it is needed to use PDPP.
-Discord, mailing list, comments. Nothing to sign, so regulators can take part off the record.
- Channels and contacts ↓ -Sign the Principles and go on the public list. Open now.
- -Get an implementation verified. Partners get drafts early, sit in working groups and vote. Organisations only, from 14 November.
- How verification works ↓ -Open a pull request from the template for your role and attach your evidence. A machine checks it. Pass, and you are Conformant.
-For Verified, the technical committee reviews in public and votes, and you prove your organisation exists through a recognised trust registry. You get reasons either way, and can resubmit.
-Your status is published with the date and version. Any Verified status makes you a Partner.
-Not sure which fits, or not on GitHub? Get in touch and we will sort it with you.
-| Status | -Role | -Level | -How established | -Opens | -State | -
|---|---|---|---|---|---|
| Conformant Source | Source | Automated | Declaration validates against the schema | By 14 Nov 2026 | Not open |
| Verified Source | Source | Reviewed | Published by the platform that holds the data. Committee review, identity via a recognised trust registry | By 14 Nov 2026 | Not open |
| Conformant Accessor | Accessor | Automated | Registered, submission complete. No assessment | By 14 Nov 2026 | Not open |
| Verified Accessor | Accessor | Reviewed | Legal attestation, liability on a named entity. Committee review, identity via a recognised trust registry | By 14 Nov 2026 | Not open |
| Verified Operator | Operator | Reviewed | Passes the test suite, then full committee review. Identity via a recognised trust registry | By 1 Jan 2027 | Not open |
Conformant is a machine check. Verified is a human review, and makes you a Partner. No fee at any stage.
-Applications open by 14 November.
-| Organisation | -Role | -Status | -Spec version | -Since | -State | -
|---|---|---|---|---|---|
| Nothing listed yet. |
Kept on GitHub: github.com/PDP-Connect/pdpp/register · machine readable at /register/index.json · Supporters are listed separately on the Principles page
Observe anywhere, sign nothing. Ask for a briefing.
- Contact → -A wrong description, a name that should not be listed, anything about a status. Answered within five working days.
- pdpp-dev-reports@lfdecentralizedtrust.org → -Formal review · open until 1 October 2026
-The Personal Data Portability Protocol v0.1.0 and its governance are open for public comment until 1 October.
-Step 1
-If you only have twenty minutes, read §7.
-Part A is how PDP-Connect runs from 15 October and is frozen during review. Part B is the proposed long-term structure and is where your comment will change the most. Two open questions: five steering committee seats or three, and whether one organisation one vote puts off large companies.
- Open governance → -Step 2
-Every section of the specification has a comment link that opens an issue with the section pre-filled. Say what is wrong, what you would change, and why.
- Open an issue → -Email your comments and we add them to the same public log, under whatever name you ask for.
- pdpp-dev-reports@lfdecentralizedtrust.org → -Step 3
-Every comment is logged in one public log. Substantive comments are answered: accepted, declined with a reason, or parked, and the answers are published there too. If a comment changes something substantial, the new text goes out for another 15 days before it is final. During that period we may hold one-to-one conversations with commenters.
-The Personal Data Portability Protocol
-Lets personal data move freely, with consent. Decide what an app can see, for what, and for how long.
-Habit Coach wants to access your account
-One button, everything the platform holds, for as long as the app wants. Nothing records what you agreed to, and turning it off means finding a settings page on someone else's site.
-Two fields, one purpose, three months, until a date you chose. It is recorded where you and the app can both see it, every request is checked against it, and ending it is one click. Ask for a third field, or a date outside the range, and the request is refused.
-[ 247 ] signatories since 3 September
-| Signatory | Type | Country | Version | Signed |
|---|---|---|---|---|
| [ Organisation name ] | Implementer | Netherlands | 1.0 | 2026-09-05 |
| [ Organisation name ] | Research institute | Germany | 1.0 | 2026-09-04 |
| [ First name L. ] | Individual | Australia | 1.0 | 2026-09-04 |
| [ Organisation name ] | Civil society | United Kingdom | 1.0 | 2026-09-03 |
| [ First name L. ] | Individual | United States | 1.0 | 2026-09-03 |
One specification, a reference server you can run today, and three roles to build for. Pick yours.
- -PDPP Principles · v1.0 · Published 3 September 2026
-When an individual permits a service to use information held about them by another, the permission is commonly granted in general terms and recorded nowhere the individual can examine.
-The choice is often between all of the information and none of it, and once given, the permission is rarely visible, rarely verifiable, and rarely reversible in practice. The party relying on the information carries the same uncertainty, since it holds no reliable record of what was consented to, for what purpose, or by whom. As more of daily life is mediated by systems that act on personal information, and as artificial intelligence increases what can be done with it, the absence of a specific, durable and enforceable account of what has been agreed has become a matter of general concern.
-Anyone. Individuals, companies, universities, civil society groups, and public bodies are all welcome. Individuals appear as first name and last initial; organisations by name. Your email is never shown.
-Individuals sign for themselves rather than their employer. Signing is not a commitment to build anything or a sign-off on every line of the specification, and you can withdraw by email at any time.
-We show your first name and last initial, your country, and the date. We never show your email.
-We email you to confirm. Organisations sign from an address at their own domain.
-[ 247 ] signatories since 3 September
-| Signatory | Type | Country | Version | Signed |
|---|---|---|---|---|
| [ Organisation name ] | Implementer | Netherlands | 1.0 | 2026-09-05 |
| [ Organisation name ] | Research institute | Germany | 1.0 | 2026-09-04 |
| [ First name L. ] | Individual | Australia | 1.0 | 2026-09-04 |
| [ Organisation name ] | Civil society | United Kingdom | 1.0 | 2026-09-03 |
| [ First name L. ] | Individual | United States | 1.0 | 2026-09-03 |
| [ Organisation name ] | Platform | United States | 1.0 | 2026-09-03 |
/principles/supporters.json
-Specification · v0.1.0 · Normative draft, 2026-08-14
-The specification defines three things: what an app may ask for, what the user approved, and how the server enforces the difference.
-It is built on OAuth 2.0 and RFC 9396.
-Machine readable at /llms.txt and /specification/index.json · purpose codes resolve under /purpose/
-A grant is the immutable record of what the user approved. It is issued by the authorization server after the user has acted on a selection request, and it is the only artifact a resource server consults when deciding whether to answer a query.
- -A grant MUST NOT be modified after issuance. Where the user wishes to change what an accessor may see, the authorization server MUST issue a new grant, and MUST NOT narrow or widen an existing one.
-A grant MUST record the source declaration snapshot against which it was issued. A resource server MUST evaluate every request against that snapshot, not against the current declaration.
- -Where access_mode is single_use, the resource server MUST refuse any request made after the first successful retrieval. Where it is continuous, the resource server MUST answer requests until the grant expires or is revoked, and SHOULD support incremental sync as described in §4.
A grant is represented as a JSON object. The example below is non-normative.
-// non-normative example -{ - "grant_id": "grn_8f2c1a04", - "client_id": "https://habitcoach.example/app", - "source": { "id": "https://sleeptracker.example", "official": true }, - "purpose": "https://pdpp.dev/purpose/personalisation", - "access_mode": "continuous", - "streams": [ - { - "stream": "sleep_sessions", - "fields": ["sleep_score", "duration_min"], - "range": { "from": "2026-06-01", "to": "2026-09-01" } - } - ], - "declaration_snapshot": "sha256:4c1f...9ab2", - "retention": { "max_days": 90, "on_expiry": "delete" }, - "issued_at": "2026-09-02T09:14:00Z", - "expires_at": "2026-12-01T00:00:00Z" -}- -
| Field | Required | Description |
|---|---|---|
| grant_id | Yes | Stable identifier, unique to the authorization server |
| purpose | Yes | A URI from the purpose registry in Appendix A |
| access_mode | Yes | single_use or continuous |
| declaration_snapshot | Yes | Digest of the source declaration the grant was issued against |
| retention | Yes | Maximum retention and the action on expiry |
| expires_at | No | Absent means the grant runs until revoked |
Governance · Consultation draft · Revised 2 September 2026
-Two parts. Part A is how it runs from 15 October. Part B is how we propose it runs once there is an elected committee. Both are open for comment until 1 October: how to comment.
-The specification and Part A are frozen while people comment, the Principles are published, and you can sign now. This stage ends on 15 October.
-The maintainers run things. Supporters can sign, but nobody can be verified until the review committee is named.
-Five people, at least three with no connection to Vana or Open Data Labs, chosen on published criteria and not removable by the maintainers. They review every application for verified status in public and give a decision with reasons, which the maintainers act on. Verification opens at this point.
-Partners elect a five-seat steering committee, one organisation one vote, with the Chair elected directly. The steering committee is the only body that can change the specification or grant a status, and it does both by majority vote. It appoints a technical committee, which reviews every application and every proposed change in public and recommends. The Chair records the vote and merges. This starts at 100 Partners or on 15 October 2027, whichever comes first, and not before 15 April 2027. Full detail is in Part B of the governance document.
-Before the steering committee exists, the interim technical committee recommends and the maintainers merge on that recommendation with no discretion. The shape is the same; only the body that votes is missing.
-Everything you need to build on PDPP is here: the specification, a reference server you can run today, and guidance for the parts people tend to get stuck on.
- -You have data, on a platform or in a connector, and you want apps to be able to ask for it with consent. You need to write a source declaration that validates against Core §5, then serve records through a Core §8 resource server.
Start with Core §4 and §5, then the declaration schema and the validator.
Core §5 →You are building an app or agent that needs someone's data. You ask for exactly what you need with a Core §6 selection request, receive a grant, and query within it. If you have done OAuth, this is OAuth with a stricter scope.
Start with Core §6 and §7, then the client example in the reference implementation.
Core §6 →You run the authorization server, the resource server, or both. Yours is the code that records the grant and refuses anything outside it. Core §8 is your interface contract and §9 is what the test suite will check.
Start by running the reference implementation, then read Core §8 against it.
Deploy the reference server →A complete authorization and resource server with scoped access, revocation, and an MCP endpoint so you can point an assistant at it and watch grants get enforced. Use it to see the protocol behave before you write your own.
Deploy guide →DataConnect ships signed connectors for both. Install it, grant an app one stream for one week, then revoke it, and you have seen the whole protocol.
DataConnect releases →The Collection Profile is one worked approach to collection, scheduling and refresh for connector-backed sources. Use it if you do not already have a pipeline. If you do, you conform as long as your declaration validates and your server answers §8 queries.
Collection Profile →Discovery and Trust walks through locating a provider-native declaration under RFC 9728 and what to check before accepting it. The requirements themselves are in Core §5, Declaration acceptance, and this document is the how-to.
Discovery and Trust →Every grant names a purpose from the registry. Most requests fit an existing code, and ai_training is the one that triggers a protocol-level consent step. If nothing fits you can propose one, and proposals are considered on a published cycle.
Purpose registry →Extension profiles add lexical search, aggregation and semantic query on top of Core without changing what Core means. Check whether one already covers your case before writing your own; an extension that weakens Core semantics is rejected.
Extension profiles →Follow the work, sign the Principles, or build something and get it verified. All of it is voluntary, and none of it is needed to use PDPP.
-Discord, mailing list, working sessions, comments. Nothing to sign, so regulators can take part off the record.
Channels and sessions ↓Sign the Principles and go on the public list. Open now.
Get an implementation verified. Partners get drafts early, sit in working groups and vote. Organisations only, from 14 November.
How verification works ↓Open a pull request from the template for your role and attach your evidence. A machine checks it. Pass, and you are Conformant.
For Verified, the technical committee reviews in public and votes, and you prove your organisation exists through a recognised trust registry. You get reasons either way, and can resubmit.
Your status is published with the date and version. Any Verified status makes you a Partner.
Not sure which fits, or not on GitHub? Get in touch and we will sort it with you.
-| Status | Role | Level | How established | Opens | State |
|---|---|---|---|---|---|
| Conformant Source | Source | Automated | Declaration validates against the schema | By 14 Nov 2026 | Not open |
| Verified Source | Source | Reviewed | Published by the platform that holds the data. Committee review, identity via a recognised trust registry | By 14 Nov 2026 | Not open |
| Conformant Accessor | Accessor | Automated | Registered, submission complete. No assessment | By 14 Nov 2026 | Not open |
| Verified Accessor | Accessor | Reviewed | Legal attestation, liability on a named entity. Committee review, identity via a recognised trust registry | By 14 Nov 2026 | Not open |
| Verified Operator | Operator | Reviewed | Passes the test suite, then full committee review. Identity via a recognised trust registry | By 1 Jan 2027 | Not open |
Conformant is a machine check. Verified is a human review, and makes you a Partner. No fee at any stage.
-Applications open by 14 November.
-| Organisation | Role | Status | Spec version | Since | State |
|---|---|---|---|---|---|
| Nothing listed yet. | |||||
Kept on GitHub: github.com/PDP-Connect/pdpp/register · machine readable at /register/index.json · Supporters are listed separately on the Principles page
-Observe anywhere, sign nothing. Ask for a briefing.
Contact →A wrong description, a name that should not be listed, anything about a status. Answered within five working days.
pdpp-dev-reports@lfdecentralizedtrust.org →Formal review · open until 1 October 2026
-The Personal Data Portability Protocol v0.1.0 and its governance are open for public comment until 1 October. It is one document of nine sections, about an hour to read, and every comment gets a published answer.
- -Step 1
-If you only have twenty minutes, read §7.
-Part A is how PDP-Connect runs from 15 October and is frozen during review. Part B is the proposed long-term structure and is where your comment will change the most. Two open questions: five steering committee seats or three, and whether one organisation one vote puts off large companies.
Open governance →Step 2
-Every section of the specification has a comment link that opens an issue with the section pre-filled. Say what is wrong, what you would change, and why.
Open an issue →Email your comments and we add them to the same public log, under whatever name you ask for.
pdpp-dev-reports@lfdecentralizedtrust.org →They are public and recorded, scheduled through the review period, and anything raised live is logged the same way.
Session dates →Step 3
-Every comment is logged and answered: accepted, declined with a reason, or parked. All answers are published in one log. If a comment changes something substantial, the new text goes out for another 15 days before it is final. During that period we may hold further sessions or one-to-one conversations with commenters.
-