Repository navigation
[7/14] spec(core): prohibit onward transfer by default - #296
Merged
tnunamak merged 3 commits intoSep 3, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tnunamak
force-pushed
the
spec/int0902-06-positioning
branch
from
September 2, 2026 23:48
d252af2 to
5a79872
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 2, 2026 23:48
0a33511 to
971eb4a
Compare
tnunamak
changed the title
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 01:02
971eb4a to
f9fc4d0
Compare
tnunamak
force-pushed
the
spec/int0902-06-positioning
branch
from
September 3, 2026 01:02
5a79872 to
ca7aa0c
Compare
tnunamak
force-pushed
the
spec/int0902-06-positioning
branch
from
September 3, 2026 01:25
9e8c011 to
128b3be
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 01:26
b11ce05 to
ead176e
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 01:35
ead176e to
cd42245
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 01:40
cd42245 to
cbdea32
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 01:53
6ebcf44 to
ec7b965
Compare
tnunamak
force-pushed
the
spec/int0902-06-positioning
branch
from
September 3, 2026 08:57
128b3be to
3cd6c13
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 08:57
ec7b965 to
18e5527
Compare
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 <tnunamak@gmail.com>
Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
tnunamak
force-pushed
the
spec/int0902-06-positioning
branch
from
September 3, 2026 10:11
3cd6c13 to
23c3152
Compare
tnunamak
force-pushed
the
spec/int0902-07-working-session-questions
branch
from
September 3, 2026 10:11
18e5527 to
25a599c
Compare
Base automatically changed from
spec/int0902-06-positioning
to
spec/integration-0902
September 3, 2026 10:29
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A recipient could hand its token to an ungranted party and bypass the owner decision that named the recipient.
Proposed rule: A recipient MUST NOT transfer its token or let an ungranted party exercise it; a personal server may issue a fresh owner grant for owner-held data.
Why: The two-grant personal-server arrangement is owner authorization twice, whereas token handoff gives another party access without a new owner grant.
Confidence: High on the prohibition; a supervised future transfer mechanism remains undesigned.
Assisted-by: AI