spec(core): define use and deletion duties for copies an app holds

apps/site/.gitignore

@@ -20,6 +20,8 @@ node_modules/
 /content/docs/spec-collection-profile.mdx
 /content/docs/spec-connector-ecosystem.mdx
 /content/docs/spec-core.mdx
+/content/docs/spec-access-extension.mdx
+/content/docs/spec-mcp-profile.mdx
 /content/docs/spec-data-query-api.mdx
 /content/docs/spec-discovery-and-trust.mdx
 /content/docs/governance.mdx

apps/site/content/docs/meta.json

@@ -4,6 +4,8 @@
   "pages": [
     "---Specification---",
     "spec-core",
+    "spec-access-extension",
+    "spec-mcp-profile",
     "spec-ext-lexical-search",
     "spec-ext-aggregation",
     "spec-semantic-retrieval-extension",

apps/site/next.config.mjs

@@ -144,6 +144,16 @@ const nextConfig = {
         permanent: true,
         source: "/spec-collection-profile",
       },
+      {
+        destination: "/specification/spec-access-extension",
+        permanent: true,
+        source: "/spec-access-extension",
+      },
+      {
+        destination: "/specification/spec-mcp-profile",
+        permanent: true,
+        source: "/spec-mcp-profile",
+      },
       {
         destination: "/specification/spec-architecture",
         permanent: true,

apps/site/scripts/sync-spec-docs.mjs

@@ -41,12 +41,14 @@ const headerDir = path.join(siteDir, "spec-headers");
 // Non-spec docs (reference-implementation*, open-questions, extension specs,
 // index, README) live only under content/docs and are NOT touched here.
 const SPECS = [
+    "spec-access-extension",
     "spec-architecture",
     "spec-auth-design",
     "spec-change-tracking",
     "spec-collection-profile",
     "spec-connector-ecosystem",
     "spec-core",
+    "spec-mcp-profile",
     "spec-data-query-api",
     "spec-discovery-and-trust",
 ];
@@ -74,7 +76,12 @@ function toMdxSafe(body) {
         // as the start of a tag name; `)` cannot start a tag name, so the parse
         // fails. Backtick-quoting it (already how this table quotes every other
         // token) makes the comparison operator literal.
-        .replace("(exclusive, <), evaluated", "(exclusive, `<`), evaluated"));
+        .replace("(exclusive, <), evaluated", "(exclusive, `<`), evaluated")
+        // MDX does not accept HTML comments (`<!--` fails as a tag name). The
+        // root specs use single-line editorial markers such as
+        // `<!-- OWNER DECISION OD-4 -->` next to a value; carry them into the
+        // site copy as MDX comments so they stay invisible there too.
+        .replace(/<!--[ \t]*(.*?)[ \t]*-->/g, "{/* $1 */}"));
 }
 // Root header shape (uniform across all spec files):
 //   line 1: `# <Title>`

apps/site/scripts/sync-spec-docs.mts

@@ -45,12 +45,14 @@ const headerDir = path.join(siteDir, "spec-headers");
 // Non-spec docs (reference-implementation*, open-questions, extension specs,
 // index, README) live only under content/docs and are NOT touched here.
 const SPECS = [
+  "spec-access-extension",
   "spec-architecture",
   "spec-auth-design",
   "spec-change-tracking",
   "spec-collection-profile",
   "spec-connector-ecosystem",
   "spec-core",
+  "spec-mcp-profile",
   "spec-data-query-api",
   "spec-discovery-and-trust",
 ];
@@ -81,6 +83,11 @@ function toMdxSafe(body) {
       // fails. Backtick-quoting it (already how this table quotes every other
       // token) makes the comparison operator literal.
       .replace("(exclusive, <), evaluated", "(exclusive, `<`), evaluated")
+      // MDX does not accept HTML comments (`<!--` fails as a tag name). The
+      // root specs use single-line editorial markers such as
+      // `<!-- OWNER DECISION OD-4 -->` next to a value; carry them into the
+      // site copy as MDX comments so they stay invisible there too.
+      .replace(/<!--[ \t]*(.*?)[ \t]*-->/g, "{/* $1 */}")
   );
 }
 

apps/site/spec-headers/spec-access-extension.header.md

@@ -0,0 +1,8 @@
+---
+title: Extended access profile
+description: Optional owner-selected authorization, grant packages, and presentation reads.
+---
+
+<Callout type="warn">
+Draft. Implementation and interoperability remain to be tested.
+</Callout>

apps/site/spec-headers/spec-mcp-profile.header.md

@@ -0,0 +1,8 @@
+---
+title: MCP read profile
+description: Draft binding of MCP tool access to PDPP grants.
+---
+
+<Callout type="warn">
+Draft. Not an adopted standard or implemented conformance claim.
+</Callout>

apps/site/src/app/(concept)/build/page.tsx

@@ -97,7 +97,7 @@ const FAQS: readonly Faq[] = [
     role: "Building an accessor",
     question: "Which purpose code do I put in my request?",
     answer:
-      "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.",
+      "Every grant names a purpose from the registry. Most requests fit an existing code. If nothing fits you can propose one, and proposals are considered on a published cycle. Under the revised Core draft, a purpose never authorizes AI training: training is a separate processing permission that stays unavailable until the AI Training Profile is published and registered.",
     cta: "Purpose registry",
     href: "/specification#purpose-registry",
   },

apps/site/src/components/sections/reference-app.tsx

@@ -1889,7 +1889,10 @@ Content-Type: application/json
                 monogram instead of fetching arbitrary remote logos.
               </p>
               <p>
-                ai_training purpose code requires explicit affirmative consent — the sole protocol-level requirement.
+                The revised Core draft reserves AI training as a separate processing permission. Training remains
+                unavailable until the AI Training Profile is published and registered. The reference implementation
+                still uses the earlier purpose-code consent rule; that rule confers no training authority under the
+                revised draft.
               </p>
             </DetailPanel>
           }
@@ -2222,8 +2225,11 @@ Introspection cache TTL ≤ 60 seconds
 RS sees revocation within max(token_exp, 60s)`}
               </pre>
               <p>
-                Revocation stops <em>future</em> access only. Records already delivered are governed by the grant's
-                retention policy and legal obligations. PDPP does not retroactively reach into client-side data stores.
+                Revocation ends <em>future</em> reads. On owner withdrawal, the owner chooses keep or delete for held
+                data. Keep permits only the grant's surviving use: ordinary grants allow use within purpose and
+                retention; processing-permission grants allow custody only, subject to the learned-parameter exception.
+                Delete is an erasure instruction the client must act on. Clients learn of it through the grant lifecycle
+                operation.
               </p>
               <p>
                 Grant narrowing is not supported in v0.1. Scope reduction: revoke the existing grant, issue a new

apps/site/src/lib/spec-nav-slugs.ts

@@ -34,6 +34,8 @@ export const PRIMARY_SLUGS = ["spec-core"] as const;
 export const GUIDANCE_SLUGS = [
   "spec-discovery-and-trust",
   "spec-collection-profile",
+  "spec-access-extension",
+  "spec-mcp-profile",
   "spec-ext-lexical-search",
   "spec-ext-aggregation",
   "spec-semantic-retrieval-extension",
@@ -54,12 +56,14 @@ export const GUIDANCE_SLUGS = [
 // the self-host coverage table) reads it from here so the two lists cannot
 // silently diverge in three different places instead of one.
 export const GENERATED_MDX_SPEC_SLUGS = [
+  "spec-access-extension",
   "spec-architecture",
   "spec-auth-design",
   "spec-change-tracking",
   "spec-collection-profile",
   "spec-connector-ecosystem",
   "spec-core",
+  "spec-mcp-profile",
   "spec-data-query-api",
   "spec-discovery-and-trust",
 ] as const;

docs/reference/consultation-agenda.md

@@ -255,6 +255,12 @@ policy and applicable legal obligations. The specification deliberately does
 not overload revocation responses or introspection state to imply downstream
 erasure, and no active erasure signal is defined in v0.1.
 
+**Superseded.** The paragraph above records the position the consultation
+opened on. A proposed held-data revision would replace it: every owner withdrawal carries a
+keep or delete disposition, and clients learn of erasure instructions through
+the grant lifecycle operation
+([spec-core, held data](https://www.pdpp.dev/docs/spec-core#held-data)).
+
 **What input helps.** Prior art on machine-to-machine deletion requests and
 their acknowledgment (including how legal-hold and retention obligations are
 represented). A view on whether erasure belongs in Core or in a companion

scripts/spec-check.ts

@@ -192,11 +192,17 @@ const ANCHOR_ID_PATTERN = /[ \t]+[[{]#[A-Za-z0-9_-]+[\]}]/g;
 // expected, allowlisted difference rather than reported drift.
 const BARE_LT_ESCAPE_PATTERN = /\(exclusive, `<`\), evaluated/g;
 
+// sync-spec-docs.mjs's toMdxSafe also turns a root HTML comment such as
+// `<!-- OWNER DECISION OD-4 -->` into an MDX comment `{/* OWNER DECISION OD-4 */}`,
+// because MDX rejects `<!--`. Map the site form back to the root form.
+const MDX_COMMENT_PATTERN = /\{\/\* (.*?) \*\/\}/g;
+
 function normalizeBody(text: string): string {
   return text
     .replace(CRLF_PATTERN, "\n")
     .replace(ANCHOR_ID_PATTERN, "")
     .replace(BARE_LT_ESCAPE_PATTERN, "(exclusive, <), evaluated")
+    .replace(MDX_COMMENT_PATTERN, "<!-- $1 -->")
     .split("\n")
     .map((line) => line.trimEnd())
     .join("\n")