Consolidate normative scope into Core: declaration acceptance moved from Discovery and Trust; Collection Profile and Discovery and Trust become informative - #283
Closed
artvana wants to merge 2 commits into
Conversation
Before the 3 September lock, the normative surface becomes Core alone. Core §5 gains "Declaration acceptance", which states in RFC 2119 terms what was previously only in the Discovery and Trust companion: a declaration is accepted through onboarding, an installed catalog, an accepted registry entry or local provisioning, and a client MUST NOT introduce a source authority or declaration URI during authorization; provider_native source.id MUST equal the already-accepted protected-resource identifier; publisher.id is an unauthenticated claim absent a binding; an accepted revision is keyed by authority binding, source.id and declaration_version, and different content under an accepted key is equivocation; retrieval MUST be HTTPS without ambient credentials, MUST enforce size, time and redirect-depth limits, MUST validate every redirect target, MUST resolve DNS freshly, MUST reject remote-schema retrieval and MUST fail closed; display values MUST be escaped; current capabilities MUST NOT widen an issued grant. §1's scope row for §5 no longer lists declaration discovery and trust as another layer, and §5's note points at the informative document for mechanics. spec-discovery-and-trust.md and spec-collection-profile.md become informative. Discovery and Trust loses its RFC 2119 keyword paragraph; the Collection Profile states that a connector conforms by producing a declaration valid under Core §5 and serving through a resource server conforming to Core §8. Content is otherwise intact. Two lines in Core contradicted the demotion and are corrected with it: the Requirements Language section said the Collection Profile "uses the same requirements language", and §1 said it "standardizes" the collection bridge. README's Normative list is Core alone, both documents move to Informative with their new descriptions, and the authority order names the normative spec. The site rail, meta.json and docs index list the two under "Implementer guidance" rather than beside Core, and each site copy carries an informative callout. GOVERNANCE.md §5.5 states the same connector conformance rule. Date headers on the three edited specs are stamped 2026-09-02. Four other specs were already stale under `pnpm spec:dates` and are left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NECjjZbYWNTzq3bu7nuiDP Signed-off-by: Art A <129354338+artvana@users.noreply.github.com>
Generated from the root GOVERNANCE.md by that spike's own sync-canonical-content.mjs, so it carries the §5.5 connector conformance sentence rather than drifting again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NECjjZbYWNTzq3bu7nuiDP Signed-off-by: Art A <129354338+artvana@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tnunamak
added a commit
that referenced
this pull request
Sep 2, 2026
…gateway OWNER-DECISION: normative (adds one SHOULD NOT). Not ratified. Sources: Geneva notes (c) and (f), relayed 2026-09-02: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788337128917169 and the owner's clarification in-thread: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788342568209169 "the spec could refer to authorization and resource servers without defining how data gets into the resource server ... The Collection Profile spec can define how data connectors can get data into a resource server." Note (f) asked for a sanity check on a personal server acting as a gateway to platform data using an owner credential against the platform's PDPP API. Two additions to Section 3, after Example B. First, Core states plainly that it defines no ingest path and that conformance does not depend on one. Section 3 already called its two examples a spectrum rather than a closed set; this says the same thing as a statement about Core's scope rather than as a caveat about the examples. Second, the gateway idea is recorded as already permitted, because it is: the personal server is a conformant client in the first relationship and a conformant resource server in the second. Nothing new is needed to build it. The open part is not whether it works but what the onward grant may say about the originating one, so the paragraph names that question and adds an interim SHOULD NOT against issuing an onward grant broader or longer than the grant the records arrived under. WHAT THIS DOES NOT DO, and why: The instinct in note (c) was that connectors and native mode "are currently superficial and can be edited out of the core spec entirely". They are not superficial, and this branch does not remove them. `source.kind` is a required field of the source declaration, its two values are validated against the accepted declaration before consent, a mismatch is a Source validation failure, and the derived provenance is recorded in consent evidence and in the issued grant. Art's open #283 adds a further normative rule keyed on `provider_native`. Removing `source.kind` is a breaking change to the declaration schema and the grant, not an editorial deletion, and it would conflict with #283 rather than compose with it. What note (c) actually asked for -- that Core not define how data reaches the resource server -- is what this commit states, and what #283 delivers from the other direction by making the Collection Profile informative. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
tnunamak
added a commit
that referenced
this pull request
Sep 2, 2026
OWNER-DECISION: normative. Three new requirements in Core; two documents demoted out of the normative set. Not ratified. Source: owner scope addendum 2026-09-02 ~17:40, item B; text taken from the sibling audit at local/SPEC-SURFACE-AUDIT-0902.md (inserts A, B and C of its section 1.5). The audit is read-only analysis by a separate lane; this commit applies its proposed text, it does not re-derive it. Art wants v0.1.0's normative surface to be the core spec alone. The audit traced what actually depends on the two companion documents and found the load-bearing residue is about 200 words. Applied here: 1. Equivocation, into Section 5 Versioning and snapshots. Core already said declaration_version is opaque with no implied ordering; it never said what happens when the SAME version label later carries DIFFERENT content. That is the security property -- it is what stops a publisher swapping content under a label an authorization server already consented against -- and it was the single genuine gap. Now a MUST. 2. Source acceptance, as a new Section 6 subsection. Core described what a selection request contains, never what it may not name. The rule that a client cannot introduce a source authority, declaration location, or revision during authorization is enforced fail-closed in the reference implementation's PAR path today; Core now states it. 3. Publisher attribution, replacing two dangling pointers. Core deferred twice to "discovery and trust policy" -- a document that, after Art's #279 removes Official Source, has zero inbound references anywhere in the repository. The rule is now stated where the field is defined. Both companion documents are relabelled Informative in their root status lines, and both header sidecars gain the Informative callout they never had, so the site stops rendering them beside Core with no visible status distinction. WHAT THIS DELIBERATELY DOES NOT DO: The Collection Profile is NOT moved to data-connectors tonight, on the audit's recommendation and for a reason worth repeating: a manifest written to its published bindings table is rejected by the reference implementation's own validator (the spec publishes `browser_automation`; the validator accepts `browser` and hard-rejects unknown keys; 0 of 45 shipping manifests use the published name). Moving a known-wrong contract into the repo whose authors are its primary readers ships the defect to exactly the people most likely to follow it. Reclassify now, refresh, then move something true. The three extension profiles are left alone. They are already allowlisted in ratified OpenSpec governance, CI-enforced, status-labelled, and required not to be depended on by Core. They are the pattern, not the problem. README.md and the site rail's grouping are NOT touched here, though both are stale in exactly this respect. Art's open #283 makes those same edits. Duplicating them guarantees a conflict and gains nothing. The slug list keeps a comment explaining why it was left unrestructured. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
This was referenced Sep 2, 2026
tnunamak
added a commit
that referenced
this pull request
Sep 2, 2026
…gateway OWNER-DECISION: normative (adds one SHOULD NOT). Not ratified. Sources: Geneva notes (c) and (f), relayed 2026-09-02: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788337128917169 and the owner's clarification in-thread: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788342568209169 "the spec could refer to authorization and resource servers without defining how data gets into the resource server ... The Collection Profile spec can define how data connectors can get data into a resource server." Note (f) asked for a sanity check on a personal server acting as a gateway to platform data using an owner credential against the platform's PDPP API. Two additions to Section 3, after Example B. First, Core states plainly that it defines no ingest path and that conformance does not depend on one. Section 3 already called its two examples a spectrum rather than a closed set; this says the same thing as a statement about Core's scope rather than as a caveat about the examples. Second, the gateway idea is recorded as already permitted, because it is: the personal server is a conformant client in the first relationship and a conformant resource server in the second. Nothing new is needed to build it. The open part is not whether it works but what the onward grant may say about the originating one, so the paragraph names that question and adds an interim SHOULD NOT against issuing an onward grant broader or longer than the grant the records arrived under. WHAT THIS DOES NOT DO, and why: The instinct in note (c) was that connectors and native mode "are currently superficial and can be edited out of the core spec entirely". They are not superficial, and this branch does not remove them. `source.kind` is a required field of the source declaration, its two values are validated against the accepted declaration before consent, a mismatch is a Source validation failure, and the derived provenance is recorded in consent evidence and in the issued grant. Art's open #283 adds a further normative rule keyed on `provider_native`. Removing `source.kind` is a breaking change to the declaration schema and the grant, not an editorial deletion, and it would conflict with #283 rather than compose with it. What note (c) actually asked for -- that Core not define how data reaches the resource server -- is what this commit states, and what #283 delivers from the other direction by making the Collection Profile informative. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
tnunamak
added a commit
that referenced
this pull request
Sep 2, 2026
OWNER-DECISION: normative. Three new requirements in Core; two documents demoted out of the normative set. Not ratified. Source: owner scope addendum 2026-09-02 ~17:40, item B; text taken from the sibling audit at local/SPEC-SURFACE-AUDIT-0902.md (inserts A, B and C of its section 1.5). The audit is read-only analysis by a separate lane; this commit applies its proposed text, it does not re-derive it. Art wants v0.1.0's normative surface to be the core spec alone. The audit traced what actually depends on the two companion documents and found the load-bearing residue is about 200 words. Applied here: 1. Equivocation, into Section 5 Versioning and snapshots. Core already said declaration_version is opaque with no implied ordering; it never said what happens when the SAME version label later carries DIFFERENT content. That is the security property -- it is what stops a publisher swapping content under a label an authorization server already consented against -- and it was the single genuine gap. Now a MUST. 2. Source acceptance, as a new Section 6 subsection. Core described what a selection request contains, never what it may not name. The rule that a client cannot introduce a source authority, declaration location, or revision during authorization is enforced fail-closed in the reference implementation's PAR path today; Core now states it. 3. Publisher attribution, replacing two dangling pointers. Core deferred twice to "discovery and trust policy" -- a document that, after Art's #279 removes Official Source, has zero inbound references anywhere in the repository. The rule is now stated where the field is defined. Both companion documents are relabelled Informative in their root status lines, and both header sidecars gain the Informative callout they never had, so the site stops rendering them beside Core with no visible status distinction. WHAT THIS DELIBERATELY DOES NOT DO: The Collection Profile is NOT moved to data-connectors tonight, on the audit's recommendation and for a reason worth repeating: a manifest written to its published bindings table is rejected by the reference implementation's own validator (the spec publishes `browser_automation`; the validator accepts `browser` and hard-rejects unknown keys; 0 of 45 shipping manifests use the published name). Moving a known-wrong contract into the repo whose authors are its primary readers ships the defect to exactly the people most likely to follow it. Reclassify now, refresh, then move something true. The three extension profiles are left alone. They are already allowlisted in ratified OpenSpec governance, CI-enforced, status-labelled, and required not to be depended on by Core. They are the pattern, not the problem. README.md and the site rail's grouping are NOT touched here, though both are stale in exactly this respect. Art's open #283 makes those same edits. Duplicating them guarantees a conflict and gains nothing. The slug list keeps a comment explaining why it was left unrestructured. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
tnunamak
added a commit
that referenced
this pull request
Sep 3, 2026
…gateway OWNER-DECISION: normative (adds one SHOULD NOT). Not ratified. Sources: Geneva notes (c) and (f), relayed 2026-09-02: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788337128917169 and the owner's clarification in-thread: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788342568209169 "the spec could refer to authorization and resource servers without defining how data gets into the resource server ... The Collection Profile spec can define how data connectors can get data into a resource server." Note (f) asked for a sanity check on a personal server acting as a gateway to platform data using an owner credential against the platform's PDPP API. Two additions to Section 3, after Example B. First, Core states plainly that it defines no ingest path and that conformance does not depend on one. Section 3 already called its two examples a spectrum rather than a closed set; this says the same thing as a statement about Core's scope rather than as a caveat about the examples. Second, the gateway idea is recorded as already permitted, because it is: the personal server is a conformant client in the first relationship and a conformant resource server in the second. Nothing new is needed to build it. The open part is not whether it works but what the onward grant may say about the originating one, so the paragraph names that question and adds an interim SHOULD NOT against issuing an onward grant broader or longer than the grant the records arrived under. WHAT THIS DOES NOT DO, and why: The instinct in note (c) was that connectors and native mode "are currently superficial and can be edited out of the core spec entirely". They are not superficial, and this branch does not remove them. `source.kind` is a required field of the source declaration, its two values are validated against the accepted declaration before consent, a mismatch is a Source validation failure, and the derived provenance is recorded in consent evidence and in the issued grant. Art's open #283 adds a further normative rule keyed on `provider_native`. Removing `source.kind` is a breaking change to the declaration schema and the grant, not an editorial deletion, and it would conflict with #283 rather than compose with it. What note (c) actually asked for -- that Core not define how data reaches the resource server -- is what this commit states, and what #283 delivers from the other direction by making the Collection Profile informative. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
Contributor
Author
tnunamak
added a commit
that referenced
this pull request
Sep 3, 2026
…gateway OWNER-DECISION: normative (adds one SHOULD NOT). Not ratified. Sources: Geneva notes (c) and (f), relayed 2026-09-02: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788337128917169 and the owner's clarification in-thread: https://vana-org.slack.com/archives/C0B9AKY6ZDH/p1788342568209169 "the spec could refer to authorization and resource servers without defining how data gets into the resource server ... The Collection Profile spec can define how data connectors can get data into a resource server." Note (f) asked for a sanity check on a personal server acting as a gateway to platform data using an owner credential against the platform's PDPP API. Two additions to Section 3, after Example B. First, Core states plainly that it defines no ingest path and that conformance does not depend on one. Section 3 already called its two examples a spectrum rather than a closed set; this says the same thing as a statement about Core's scope rather than as a caveat about the examples. Second, the gateway idea is recorded as already permitted, because it is: the personal server is a conformant client in the first relationship and a conformant resource server in the second. Nothing new is needed to build it. The open part is not whether it works but what the onward grant may say about the originating one, so the paragraph names that question and adds an interim SHOULD NOT against issuing an onward grant broader or longer than the grant the records arrived under. WHAT THIS DOES NOT DO, and why: The instinct in note (c) was that connectors and native mode "are currently superficial and can be edited out of the core spec entirely". They are not superficial, and this branch does not remove them. `source.kind` is a required field of the source declaration, its two values are validated against the accepted declaration before consent, a mismatch is a Source validation failure, and the derived provenance is recorded in consent evidence and in the issued grant. Art's open #283 adds a further normative rule keyed on `provider_native`. Removing `source.kind` is a breaking change to the declaration schema and the grant, not an editorial deletion, and it would conflict with #283 rather than compose with it. What note (c) actually asked for -- that Core not define how data reaches the resource server -- is what this commit states, and what #283 delivers from the other direction by making the Collection Profile informative. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
Contributor
|
Superseded by #285, merged to main as 99fcca3. This PR's commits were carried into that stack with authorship preserved (as #307 for the governance model and #308 for the normative-scope consolidation), with the follow-on changes recorded in the stack's decision rows. Closing without merge so the history has one path. |
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
2 participants
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.
Narrows the normative surface to Core before the 3 September lock. Everything a conformant implementation must do is now stated in one document.
Stacked on #279 (
docs/governance-remove-steward), because change F editsGOVERNANCE.md§5.5, which exists only on that branch. Merge #279 first, or retarget this atmainonce it lands.A. Core §5 gains "Declaration acceptance"
New subsection after "Versioning and snapshots", in RFC 2119 terms, stating what was previously only in the Discovery and Trust companion:
provider_native,source.idMUST equal the already-accepted protected-resource identifier, and a mismatchedsource.idorsource.kindMUST be rejected before consent or grant issuance;publisher.idis an unauthenticated claim absent an accepted channel or configured mapping, and MUST NOT be relied on for acceptance, attribution, redirect policy or any other trust decision;source.idanddeclaration_version; different parsed content under an accepted key is equivocation and MUST be rejected, with no ordering or freshness inferred fromdeclaration_version;§1's scope row for §5 no longer lists declaration discovery and trust as another layer and now names declaration acceptance as in scope. §5's opening note points at the informative document for retrieval mechanics.
B. Discovery and Trust becomes informative
Status header now reads "Informative. Implementation guidance. Normative requirements moved to Core §5 Declaration acceptance on 2026-09-02." The RFC 2119 keyword paragraph is removed. Content otherwise intact.
C. Collection Profile becomes informative
Status header now reads "Informative. Builder guidance for connector collection. Not a conformance requirement.", followed by: "A connector conforms to PDPP by producing a source declaration valid under Core §5 and serving its data through a resource server conforming to Core §8. No particular collection method is required."
D. README
Normative is Core alone. Both documents move to Informative with their new descriptions. The authority order now reads "the normative spec (
spec-core.md)", and the lead paragraph says one root spec is normative rather than three.E. Site
pnpm spec:checkpasses — 9 canonical pairs, 3 site-only extensions, 1 reference-only root spec.PRIMARY_SLUGSis Core plus the three extension profiles. The two demoted documents move to a newGUIDANCE_SLUGSunder a third rail heading, Implementer guidance, registered inrail.tsx'sRAIL_SECTION_LABELS.content/docs/meta.jsongains anImplementer guidanceseparator and lists them under it./docs/...hrefs are corrected to/specification/....descriptions say informative.F. GOVERNANCE.md
§5.5 states, after the Conformant Source paragraph, that a connector source conforms by producing a declaration validating against Core §5 and serving through a resource server conforming to Core §8, with no particular collection method required.
Two corrections that came with the demotion
Both were direct contradictions once the two documents became informative, so they are fixed here rather than left to contradict the status headers:
Notes
Date:headers on the three edited specs are stamped2026-09-02.pnpm spec:dateswas already failing onmainforspec-connector-ecosystem.md,spec-deferred.mdandspec-reference-implementation-examples.md; those are untouched, since stamping them would claim a substantive change that did not happen here.apps/site-blume-spike/content/governance.mdis regenerated from the root document by that spike's ownsync-canonical-content.mjs.Checks
spec:checkpasses.pnpm --dir apps/site types:check,test(202 passed, 0 failed),check(0 errors; the 4suppressions/unusedwarnings are pre-existing) andbuildall pass.Verified on the served production build:
/specification,/specification/spec-discovery-and-trustand/specification/spec-collection-profileall return 200; the rail renders Specification (Core plus the three extensions), then Implementer guidance (the two demoted documents), then Programme; the informative callouts render on both guidance pages; andid="declaration-acceptance"resolves on/specificationwith the new subsection's text present.Assisted-by: AI
🤖 Generated with Claude Code
https://claude.ai/code/session_01NECjjZbYWNTzq3bu7nuiDP