From 982157d3977789d5241ad08587978534c554a8a5 Mon Sep 17 00:00:00 2001 From: Tim Nunamaker Date: Wed, 2 Sep 2026 17:35:24 -0500 Subject: [PATCH 1/3] spec(deferred): record the working-session questions that had no home OWNER-DECISION: not normative. Three open questions recorded, no requirement added or changed. Not ratified. Source: PDPP working session on grants, 2026-08-19, recapped in #vana-org by Kat: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1787246400660469 and in the session summary: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1787249010667589 The recap listed six questions and named the owner as the next step on several. Grepping the specification set for each: subgrants, change of client ownership, undisclosed sub-processing, ISO MyTerms and bulk export appear nowhere in any spec-*.md file. They existed only in Slack and in the session recording. Three entries are added so they are referenceable from Core and survive the next person who looks. The other two questions in that recap already have homes and are not duplicated here: cursor-based sync prior art (WebDAV report/sync token and the rest) is a design input rather than an open question, and the adoption argument is not a specification concern. Subgrants and change-of-ownership are stated as questions with a v0.1 posture, not as answers. The bulk export entry records that half of it is already decided -- owner self-export is a SHOULD-level RS conformance item in Core Section 9 -- so the open part is only the client-under-grant case. The change-of-ownership entry says `client_claims` is not an ownership record and must not be read as one. That is a reading of the existing trust-boundary text, which already says client claims are self-asserted, unverifiable, and outside the resolved grant. If it reads as a new restriction rather than a restatement, it should be cut. Assisted-by: AI Signed-off-by: Tim Nunamaker --- spec-deferred.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/spec-deferred.md b/spec-deferred.md index ef9bf4f43..9a2a74ce4 100644 --- a/spec-deferred.md +++ b/spec-deferred.md @@ -177,6 +177,38 @@ _Newly deferred (2026-09-02)._ **v0.1 posture:** Out of scope. Grants bind to a single `source.id`. A user wanting a category across five providers issues five grants today. +### Subgrants + +_Newly deferred (2026-09-02; raised in the 2026-08-19 working session)._ + +**Description:** Whether a client holding a grant may pass a narrower piece of that access on to another party, without the owner issuing a second grant directly. + +**Why it is open:** A grant is immutable and bound to one `client_id`. A subgrant needs a rule for what the owner sees and approves, whether the subgrantee is visible to the owner at all, how revocation of the parent reaches the child, and whether a subgrant can outlive its parent. Answering it badly produces exactly the re-delegation surface the grant model exists to prevent. + +**v0.1 posture:** Out of scope. Access under a grant is not transferable, and a second party needs its own grant. + +### Change of client ownership and undisclosed sub-processing + +_Newly deferred (2026-09-02; raised in the 2026-08-19 working session)._ + +**Description:** An owner grants access to a client on assumptions about that specific relationship. If the client is acquired, changes legal structure, or outsources processing to a third party the owner never saw, those assumptions no longer hold, and the grant does not know it. + +**Why it is open:** The protocol has no representation of who the client is as a legal entity, and no event by which a change of control could reach an issued grant. One suggestion from the session was to require clients to declare ownership type. Whether that belongs in the protocol, in the conformance programme, or nowhere is undecided, as is whether a change of control should force revocation, force re-consent, or merely be disclosed. + +**Related:** ISO MyTerms was raised in the same discussion as prior art for owner-specified terms under which a first party holds data. It has not been evaluated for fit, and whether owner-specified terms belong in Core, in a companion RFC with the authorization server holding templates, or outside PDPP entirely is itself open. + +**v0.1 posture:** Out of scope. `client_claims` carries client-authored, explicitly non-enforceable statements about a specific request; it is not an ownership record and must not be read as one. + +### Bulk export as a distinct access path + +_Newly deferred (2026-09-02; raised in the 2026-08-19 working session)._ + +**Description:** PDPP has focused on continuous synchronization rather than a Takeout-style bulk export. The question raised was whether export deserves its own defined access path rather than being left as a special case of query. + +**Why it is open:** Core already has owner-token self-export as a SHOULD-level resource server conformance item (Section 9), so the primitive exists. What does not exist is a defined export path for a client under a grant, or an answer to whether a bulk export differs from paginating the same query to its end in anything other than convenience. + +**v0.1 posture:** Owner self-export is in scope at SHOULD level. Client-side bulk export is not defined and is served, if at all, by ordinary paginated query under the grant. + ### Trust Registry Query Protocol (TRQP) as the register interface _Newly deferred (2026-09-02)._ From 7f96b03fdc97e5f53f88c2cefec53f0a8e7301b4 Mon Sep 17 00:00:00 2001 From: Tim Nunamaker Date: Wed, 2 Sep 2026 20:40:26 -0500 Subject: [PATCH 2/3] spec: add narrowed onward-transfer invariant Assisted-by: AI Signed-off-by: Tim Nunamaker --- spec-core.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/spec-core.md b/spec-core.md index e1291c43b..562bbbee1 100644 --- a/spec-core.md +++ b/spec-core.md @@ -182,6 +182,8 @@ PDPP therefore defines no delegated-grant, sub-grant, or grant-chaining construc Only live passthrough is bounded by the upstream grant: when the personal server does not hold a copy and reads from the platform to fulfill a downstream request, it MUST stay within the upstream grant. This limit does not constrain a fresh grant for owner-held data. A downstream PDPP token is never forwarded upstream. +**Onward transfer is prohibited.** A recipient MUST NOT transfer its token or let an ungranted party exercise it. A personal server MAY disclose owner-held data under a fresh owner-issued downstream grant. Only live passthrough is bounded by the upstream grant, and a downstream PDPP token is never forwarded upstream. + A different topology — the owner running their own authorization server in front of a platform's data, so that the platform holds the data but the owner's server decides who may read it — is not introduced by this specification. It is the arrangement UMA describes, it is not the arrangement above, and it is recorded as deferred rather than left ambiguous. ### Protocol layering From 25a599c92757238ba173b99a94f80b08203d9d66 Mon Sep 17 00:00:00 2001 From: Tim Nunamaker Date: Wed, 2 Sep 2026 20:53:26 -0500 Subject: [PATCH 3/3] spec: narrow onward transfer rule Assisted-by: AI Signed-off-by: Tim Nunamaker --- spec-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec-core.md b/spec-core.md index 562bbbee1..6bfb802f9 100644 --- a/spec-core.md +++ b/spec-core.md @@ -182,7 +182,7 @@ PDPP therefore defines no delegated-grant, sub-grant, or grant-chaining construc Only live passthrough is bounded by the upstream grant: when the personal server does not hold a copy and reads from the platform to fulfill a downstream request, it MUST stay within the upstream grant. This limit does not constrain a fresh grant for owner-held data. A downstream PDPP token is never forwarded upstream. -**Onward transfer is prohibited.** A recipient MUST NOT transfer its token or let an ungranted party exercise it. A personal server MAY disclose owner-held data under a fresh owner-issued downstream grant. Only live passthrough is bounded by the upstream grant, and a downstream PDPP token is never forwarded upstream. +**Onward transfer is prohibited.** A recipient MUST NOT transfer its token or let an ungranted party exercise it. A different topology — the owner running their own authorization server in front of a platform's data, so that the platform holds the data but the owner's server decides who may read it — is not introduced by this specification. It is the arrangement UMA describes, it is not the arrangement above, and it is recorded as deferred rather than left ambiguous.