Attribution / Health Warning: Came across this while building some toy Pinterest data connector files against the manifest/query-affordance model. Investigation and write-up assisted by Claude (Anthropic); I've reviewed the spec citations myself before posting. Sorry if this misses anything in CONTRIBUTING.md, I read it, but am new here!
Summary
Spec §5/§6 define resources[] as a fully protocol-enforced way to scope a grant to specific record IDs. Working through it while building a local connector, I can't find any point in the flow where a client learns which record IDs exist to request from the user in the first place. As written, resources[] only works if the client already has exact IDs from somewhere outside the protocol. Wanted to check whether that's intentional for v0.1 (e.g. resources[] is meant for a client re-requesting against records it already saw under a prior broader grant) or a known gap, before assuming either.
What the spec says
resources | string[] | Protocol-enforced | Specific record IDs to authorize. Values are canonical key strings... The AS validates arity and type against the manifest primary_key at grant issuance. The RS filters by exact primary-key match. — spec-core.md, Stream selection parameters (request-level)
This describes validation and enforcement of a resource list the client supplies. I can't find anywhere upstream of it — in spec-core.md or spec-data-query-api.md — describing how the client is meant to arrive at that list. The one section with "discovery" in its heading (Pre-registered public client discovery, spec-core.md §6) is about discovering valid client_id values for client registration; it's unrelated to discovering record IDs within a stream.
What I checked in the reference implementation
apps/console/src/components/pdpp/consent-card.tsx and grant-inspector.tsx (the consent screen and grant detail view) — no reference to resources in either.
apps/console/src/app/(console)/explore/ — a real owner-facing browse surface for already-synced records (facets, grouping, saved views). This is the closest existing thing to "a list resources could be picked from," but it's owner-only; nothing connects it to a client's request-building step or to the consent flow.
reference-implementation/server/routes/rs-read.ts — buildOwnerReadGrantForManifest, which its own comment describes as a "permissive owner read grant covering every stream" — confirming the server has a first-class concept of unrestricted owner-only reads, again disconnected from anything a requesting client can reach.
So: no pre-consent catalog/listing endpoint for a client, and no owner-side mechanism to curate a subset and hand specific IDs back to a client either. Both halves of "requester picks from a list the owner offers" are absent, not just one side.
Question
Is resources[] intentionally scoped to "client already knows the ID from a prior interaction" for v0.1, with any kind of discovery or owner-curated offer deferred deliberately? Or is this an open gap? If it's real and useful, happy to sketch what a minimal version might look like (e.g. wiring Explore's existing browse view into request-building, gated by the manifest's selection.resources flag).
Assisted-by: AI
Attribution / Health Warning: Came across this while building some toy Pinterest data connector files against the manifest/query-affordance model. Investigation and write-up assisted by Claude (Anthropic); I've reviewed the spec citations myself before posting. Sorry if this misses anything in CONTRIBUTING.md, I read it, but am new here!
Summary
Spec §5/§6 define resources[] as a fully protocol-enforced way to scope a grant to specific record IDs. Working through it while building a local connector, I can't find any point in the flow where a client learns which record IDs exist to request from the user in the first place. As written, resources[] only works if the client already has exact IDs from somewhere outside the protocol. Wanted to check whether that's intentional for v0.1 (e.g. resources[] is meant for a client re-requesting against records it already saw under a prior broader grant) or a known gap, before assuming either.
What the spec says
resources | string[] | Protocol-enforced | Specific record IDs to authorize. Values are canonical key strings... The AS validates arity and type against the manifest primary_key at grant issuance. The RS filters by exact primary-key match. — spec-core.md, Stream selection parameters (request-level)
This describes validation and enforcement of a resource list the client supplies. I can't find anywhere upstream of it — in spec-core.md or spec-data-query-api.md — describing how the client is meant to arrive at that list. The one section with "discovery" in its heading (Pre-registered public client discovery, spec-core.md §6) is about discovering valid client_id values for client registration; it's unrelated to discovering record IDs within a stream.
What I checked in the reference implementation
apps/console/src/components/pdpp/consent-card.tsx and grant-inspector.tsx (the consent screen and grant detail view) — no reference to resources in either.
apps/console/src/app/(console)/explore/ — a real owner-facing browse surface for already-synced records (facets, grouping, saved views). This is the closest existing thing to "a list resources could be picked from," but it's owner-only; nothing connects it to a client's request-building step or to the consent flow.
reference-implementation/server/routes/rs-read.ts — buildOwnerReadGrantForManifest, which its own comment describes as a "permissive owner read grant covering every stream" — confirming the server has a first-class concept of unrestricted owner-only reads, again disconnected from anything a requesting client can reach.
So: no pre-consent catalog/listing endpoint for a client, and no owner-side mechanism to curate a subset and hand specific IDs back to a client either. Both halves of "requester picks from a list the owner offers" are absent, not just one side.
Question
Is resources[] intentionally scoped to "client already knows the ID from a prior interaction" for v0.1, with any kind of discovery or owner-curated offer deferred deliberately? Or is this an open gap? If it's real and useful, happy to sketch what a minimal version might look like (e.g. wiring Explore's existing browse view into request-building, gated by the manifest's selection.resources flag).
Assisted-by: AI