@opendatalabs/personal-server-ts-core 1.33.8 → 1.34.0

package/dist/pdpp/types.d.ts

@@ -0,0 +1,441 @@
+/**
+ * PDPP Core v0.1.0 authorization types.
+ *
+ * These mirror the normative field tables in PDPP Core §6 (Selection Request)
+ * and §7 (Grant). Where this file and the spec disagree, the spec wins — §7
+ * says so explicitly about its own TypeScript mirror.
+ *
+ * The PDPP grant model is deliberately separate from the Vana chain grant in
+ * `../grants/`. That one is an EIP-712 payload binding a builder address to
+ * dot-scopes; this one is an RFC 9396 consent artifact binding an OAuth client
+ * to declaration-resolved streams. They are different authorities over
+ * different data and must not be conflated.
+ */
+/** The RFC 9396 `type` value that marks an authorization detail as PDPP. */
+export declare const PDPP_DATA_ACCESS_TYPE = "https://pdpp.dev/data-access";
+/**
+ * The v0.2 RFC 9396 `type`.
+ *
+ * v0.2 is deliberately a *separate* detail type rather than a compatible
+ * extension of v0.1. The revision changes authorization resolution (explicit
+ * minima) and disclosed-record semantics (a schema's `required` array is no
+ * longer a consent floor), so the two are not wire-compatible: the same
+ * request body resolves to a different grant under each. An AS implementing
+ * both MUST resolve each under its own revision, which is why every rule below
+ * branches on this constant rather than on the presence of a v0.2-only member.
+ *
+ * A client MUST NOT retry a rejected v0.2 request under the v0.1 type without
+ * a new authorization decision; nothing here silently downgrades one.
+ */
+export declare const PDPP_DATA_ACCESS_TYPE_V02 = "https://pdpp.dev/data-access/0.2";
+/** The v0.1 grant schema version. */
+export declare const PDPP_GRANT_VERSION = "0.1.0";
+/** The v0.2 grant schema version, issued for `PDPP_DATA_ACCESS_TYPE_V02`. */
+export declare const PDPP_GRANT_VERSION_V02 = "0.2.0";
+/**
+ * The PDPP HTTP API contract version, sent and echoed in the `PDPP-Version`
+ * header. Normative value from Core §8 "API versioning".
+ *
+ * §7 "Version layering" is explicit that the three version axes MUST NOT be
+ * conflated, and this is the one that is easiest to get wrong: it is the HTTP
+ * *contract* version, not `PDPP_GRANT_VERSION` (the grant schema, `0.1.0`) and
+ * not `source_declaration.version` (an opaque declaration revision). This
+ * previously carried the grant schema version, which meant a client pinning
+ * the spec's own header value was rejected by the AS while the RS accepted it —
+ * a client could reach only half the server.
+ *
+ * Both the AS and RS surfaces import this one constant so they cannot drift
+ * apart again.
+ */
+export declare const PDPP_API_VERSION = "2026-04-06";
+/**
+ * The one purpose code Core gives a protocol-level consent requirement
+ * (§6 "AI training consent"). Every other code is a structured policy
+ * declaration the AS displays but does not gate on.
+ */
+export declare const AI_TRAINING_PURPOSE = "https://pdpp.dev/purpose/ai_training";
+export type AccessMode = "single_use" | "continuous";
+/**
+ * Provenance class. A selection request never carries this — the AS derives it
+ * from the declaration it accepted for `source.id` (§6 "Source kinds").
+ */
+export type SourceKind = "connector" | "provider_native";
+/** RFC 7591-aligned inline client metadata, minus the redundant `client_` prefix. */
+export interface ClientDisplay {
+    name: string;
+    uri?: string;
+    logo_uri?: string;
+    policy_uri?: string;
+    tos_uri?: string;
+}
+export interface TimeRange {
+    /** Inclusive lower bound (>=). */
+    since?: string;
+    /** Exclusive upper bound (<). */
+    until?: string;
+}
+/**
+ * A v0.2 explicit authorization minimum: the floor below which the owner's
+ * narrowing cannot go without failing issuance for this stream.
+ *
+ * This describes *permission*, never data. A satisfied minimum says the grant
+ * permits those fields and that window; it asserts nothing about whether
+ * records exist in it, how fresh they are, or whether they suit the client's
+ * task. The client evaluates application sufficiency separately.
+ */
+export interface StreamMinimum {
+    /** Non-empty; declared top-level field names drawn from the expanded request. */
+    fields?: string[];
+    /** Both bounds finite, `since < until`; must sit inside the requested window. */
+    time_range?: {
+        since: string;
+        until: string;
+    };
+}
+export interface StreamRequest {
+    /** Stream name, or `*` for every stream in the retained declaration. */
+    name: string;
+    /** `required` (default) or `optional`; optional streams become owner choices. */
+    necessity?: "required" | "optional";
+    instance_ids?: string[];
+    time_range?: TimeRange;
+    /** Named AS view. Mutually exclusive with `fields`. */
+    view?: string;
+    /** Field allowlist, top-level names only. Mutually exclusive with `view`. */
+    fields?: string[];
+    /** Canonical key strings for specific records. */
+    resources?: string[];
+    /**
+     * v0.2 only. The AS recognizes exactly `fields` and `time_range` here and
+     * rejects anything else — an unknown member would otherwise read as a
+     * satisfied condition the client believes it imposed.
+     */
+    minimum?: StreamMinimum;
+}
+/**
+ * Client-authored, unverifiable statements about this specific request.
+ * Request-scoped, not entity-scoped. These never enter the resolved grant.
+ */
+export interface ClientClaims {
+    commitments?: string[];
+}
+export interface Retention {
+    /** ISO 8601 duration. */
+    max_duration: string;
+    /** `archive` is not supported in v0.1. */
+    on_expiry: "delete" | "anonymize";
+}
+/**
+ * Standing terms the recipient has already authorized, as the AS knows them.
+ *
+ * v0.2 draws a line the protocol cannot enforce after disclosure but can
+ * enforce before it: changing the *data selection* is the owner's to do, while
+ * changing the *terms of use* requires the recipient's authority. An owner can
+ * narrow what they share freely; an owner asking the recipient to hold it for
+ * a week instead of a month is proposing a different obligation, and PDPP must
+ * not record that as agreed when nobody agreed to it.
+ *
+ * The accepted lists are enumerations, not capabilities. A recipient that
+ * accepts a 7-day retention has accepted 7 days — not "whatever the owner
+ * asks, up to 7 days", and not "the ability to accept retention terms". v0.2
+ * is explicit that a capability advertisement alone is not acceptance.
+ */
+export interface RecipientTerms {
+    /** Identifies the terms. Retained with the consent evidence. */
+    id: string;
+    /**
+     * The version in force. Retained too: "the recipient agreed" is
+     * unfalsifiable later if the document can change and nothing records which
+     * text was in force at approval.
+     */
+    version: string;
+    /** Retention terms the recipient has accepted, exactly. */
+    accepted_retention?: Retention[];
+    /** Purpose codes the recipient has accepted, exactly. */
+    accepted_purpose_codes?: string[];
+}
+/**
+ * Conditions the owner attached to their approval, beyond narrowing the data.
+ *
+ * These are *proposals*, not decisions: each must be covered by the request or
+ * by recipient-authorized standing terms before it can become a commitment.
+ */
+export interface OwnerConditions {
+    retention?: Retention;
+    purpose_code?: string;
+}
+/** One RFC 9396 `authorization_details` entry of PDPP type. */
+export interface SelectionRequest {
+    type: typeof PDPP_DATA_ACCESS_TYPE | typeof PDPP_DATA_ACCESS_TYPE_V02;
+    /** A request carries `id` alone; provenance is derived, never asserted. */
+    source: {
+        id: string;
+    };
+    purpose_code: string;
+    purpose_description?: string;
+    access_mode: AccessMode;
+    retention?: Retention;
+    /** Required unless `selection_preset` is used. Exactly one of the two. */
+    streams?: StreamRequest[];
+    /** Alternative to explicit streams. Exactly one of the two. */
+    selection_preset?: string;
+    client_claims?: ClientClaims;
+}
+export interface TimeConstraint {
+    /** Frozen `consent_time_field` from the retained declaration. */
+    field: string;
+    /** Inclusive (>=). */
+    since?: string;
+    /** Exclusive (<). A hard cap: applies to future records as well as past. */
+    until?: string;
+}
+export interface StreamGrant {
+    /** Always concrete. Issued grants never contain wildcards. */
+    name: string;
+    /** Unique, non-empty. Fan-in only when more than one handle is listed. */
+    instance_ids: string[];
+    /** Unique, non-empty, resolved. Authoritative for RS enforcement. */
+    fields: string[];
+    time_constraint?: TimeConstraint;
+    /** Canonical key strings. Absent means all records in the stream. */
+    resources?: string[];
+}
+/**
+ * What the client asked for on one stream, as the grant records it alongside
+ * what was approved.
+ *
+ * v0.2 requires the grant to be the client's source of truth for the outcome,
+ * including any narrowing the owner applied. Without this the client cannot
+ * tell a narrowed grant from the request it sent — the approved `StreamGrant`
+ * alone is indistinguishable from an unnarrowed one, so a client would have to
+ * diff against its own memory of the request, which §7 forbids it from
+ * treating as authority.
+ */
+export interface RequestedStream {
+    name: string;
+    necessity: "required" | "optional";
+    /** The upper field limit as expanded from the request, before owner choices. */
+    fields: string[];
+    time_range?: TimeRange;
+    minimum?: StreamMinimum;
+}
+/** The v0.2 requested-vs-approved record. Absent on v0.1 grants. */
+export interface RequestedSelection {
+    streams: RequestedStream[];
+    /** Requested stream names the owner declined. Only optional streams can appear. */
+    omitted_streams?: string[];
+}
+export interface Grant {
+    /** `0.1.0` for v0.1 grants, `0.2.0` for v0.2. */
+    version: string;
+    grant_id: string;
+    issued_at: string;
+    subject: {
+        id: string;
+    };
+    client: {
+        client_id: string;
+        client_display?: ClientDisplay;
+    };
+    /** Retained verbatim from the accepted declaration. */
+    source: {
+        kind: SourceKind;
+        id: string;
+    };
+    /** Opaque revision of the exact snapshot used, not a live lookup authority. */
+    source_declaration: {
+        version: string;
+    };
+    purpose_code: string;
+    purpose_description?: string;
+    access_mode: AccessMode;
+    streams: StreamGrant[];
+    /** Informational; the resolved streams stay authoritative. */
+    selection_preset?: string;
+    retention?: Retention;
+    /** Absent means no expiry. */
+    expires_at?: string;
+    /**
+     * v0.2: what the client requested, beside the approved `streams` above.
+     * Absent on v0.1 grants, whose contract has no such member.
+     */
+    requested?: RequestedSelection;
+}
+/** True for a grant issued under the v0.2 detail type. */
+export declare function isV02Grant(grant: Grant): boolean;
+/**
+ * §5 "Stream display metadata": human-readable copy for the consent UI.
+ *
+ * Authored by the connector maintainer, never by the requesting client. §5:
+ * "The requesting client MUST NOT be able to override or supplement these
+ * descriptions in the selection request. This separation ensures that the
+ * consent UI's data descriptions are trustworthy regardless of the client's
+ * intentions." That is what makes this the one data description on the consent
+ * surface a hostile client cannot write.
+ */
+export interface DeclaredDisplay {
+    /** Short consent-card name, e.g. "Who you follow". */
+    label?: string;
+    /**
+     * What the data includes and, where relevant, what it EXCLUDES — e.g.
+     * "…No DMs, profile details, or follower lists." The exclusion half is the
+     * part an owner cannot reconstruct from a field list.
+     */
+    detail?: string;
+}
+export interface DeclaredStream {
+    name: string;
+    /**
+     * §5 `streams[].description`: a short summary of the stream's contents.
+     *
+     * Explicitly NOT consent-surface metadata — §5 points at `display` for that.
+     * Kept separate rather than coalesced so the AS can apply that precedence
+     * (label → description → name) instead of guessing at render time.
+     */
+    description?: string;
+    /** §5 consent-surface metadata. Absent means the declaration authored none. */
+    display?: DeclaredDisplay;
+    /**
+     * How records in this stream behave over time (§5).
+     *
+     * `mutable_state` records are upserted by key and carry version history;
+     * `append_only` records are immutable, so a duplicate key is a no-op rather
+     * than an update. Optional, defaulting to `mutable_state`, so declarations
+     * written before this field existed keep their current meaning exactly.
+     *
+     * Before this existed the RS hardcoded `mutable_state` for every stream,
+     * which made an `append_only` declaration silently coerced and the field
+     * unfalsifiable for an ingesting producer.
+     */
+    semantics?: "mutable_state" | "append_only";
+    /** Top-level field names the stream's schema defines. */
+    fields: string[];
+    /**
+     * Fields a record of this stream cannot be valid without. Always included in
+     * a resolved field set regardless of the requested allowlist — the per-stream
+     * consent floor (§6 "Note on `fields`").
+     */
+    required_fields: string[];
+    /**
+     * Presence is the authoritative signal that the stream is time-range-capable
+     * (§6 "Note on `time_range`").
+     */
+    consent_time_field?: string;
+    /** Arity of the primary key; `resources` entries are validated against it. */
+    primary_key: string[];
+    /** The stream's JSON Schema from a normative §5 declaration, when present. */
+    schema?: Record<string, unknown>;
+    /** Declared selection capabilities, e.g. `{ fields: true, resources: false }`. */
+    selection?: Record<string, unknown>;
+}
+export interface DeclaredView {
+    name: string;
+    fields: string[];
+}
+export interface DeclaredPreset {
+    name: string;
+    streams: StreamRequest[];
+}
+/**
+ * The exact declaration snapshot retained through validation, consent,
+ * issuance, and consent evidence. A later current declaration never
+ * substitutes for it (§9 AS item 16).
+ */
+export interface DeclarationSnapshot {
+    source_id: string;
+    source_kind: SourceKind;
+    /**
+     * §5 top-level `display`: the source's human-readable name for consent UIs.
+     *
+     * Without it the consent surface can only name a source by its registry URL.
+     * Absent means the declaration authored none, and the surface falls back to
+     * the id rather than rendering a blank.
+     */
+    display?: {
+        name?: string;
+    };
+    /** Opaque revision identifier recorded into the grant. */
+    version: string;
+    /** Digest over the retrieved document, verified before the snapshot is trusted. */
+    digest: string;
+    streams: DeclaredStream[];
+    views?: DeclaredView[];
+    selection_presets?: DeclaredPreset[];
+}
+export type PdppTokenKind = "owner" | "client";
+export interface PdppAuthorizationDetail {
+    type: typeof PDPP_DATA_ACCESS_TYPE;
+    source: {
+        kind: SourceKind;
+        id: string;
+    };
+    purpose_code: string;
+    purpose_description?: string;
+    access_mode: AccessMode;
+    streams: StreamGrant[];
+}
+/**
+ * The v0.2 client-visible authorization result: `{ type, grant }` carrying the
+ * complete immutable grant.
+ *
+ * v0.2 forbids substituting the original selection request or a lossy summary.
+ * The v0.1 detail above is exactly such a summary — it drops `retention`,
+ * `expires_at`, the resolved client identity, and (under v0.2) the
+ * requested-vs-approved record — so v0.2 carries the whole grant instead of a
+ * projection of it. Both shapes coexist: a token covering a v0.1 grant still
+ * returns the v0.1 detail, so an existing client sees no change.
+ */
+export interface PdppAuthorizationResultV02 {
+    type: typeof PDPP_DATA_ACCESS_TYPE_V02;
+    grant: Grant;
+}
+/** Either revision's element, as it appears in `authorization_details`. */
+export type PdppAuthorizationEntry = PdppAuthorizationDetail | PdppAuthorizationResultV02;
+/**
+ * RFC 7662 introspection response with the PDPP extension members. An inactive
+ * token returns exactly `{ active: false }` — RFC 7662 §2.2 forbids leaking
+ * anything else about a token that is revoked, expired, or simply unknown.
+ */
+export interface PdppIntrospectionResponse {
+    active: boolean;
+    pdpp_token_kind?: PdppTokenKind;
+    subject_id?: string;
+    /** Owner tokens only. Source-wide tokens may omit an instance list. */
+    instance_ids?: string[];
+    /** Owner tokens only. Limits the token to one source's connections. */
+    source_id?: string;
+    grant_id?: string;
+    client_id?: string;
+    /** Unix epoch seconds. Omitted when the token never expires. */
+    exp?: number;
+    /**
+     * One element per covered grant, in that grant's own revision shape. v0.2
+     * requires the AS to return the same resolved grant facts to the client and
+     * to an authenticated RS apart from token-specific active-state and expiry,
+     * which is why this is the same projection the token response uses.
+     */
+    authorization_details?: PdppAuthorizationEntry[];
+}
+/** Why a token did not resolve. Drives the RS error; never echoed to the client. */
+export type InactiveReason = "unknown" | "expired" | "revoked" | "grant_revoked" | "grant_expired";
+/**
+ * The co-located equivalent of an introspection call. The RS resolves a token
+ * through this one path and enforces only from the result (§8 "Grant
+ * enforcement"): no second authority, no live declaration lookup.
+ */
+export interface PdppTokenContext {
+    active: boolean;
+    tokenKind?: PdppTokenKind;
+    subjectId?: string;
+    /** Owner tokens only. The RS enforces this persisted scope directly. */
+    instanceIds?: string[];
+    /** Owner tokens only. The AS and RS enforce this source scope directly. */
+    sourceId?: string;
+    /** Client tokens only. An owner token carries no grant. */
+    grant?: Grant;
+    clientId?: string;
+    expiresAt?: string;
+    inactiveReason?: InactiveReason;
+}
+export type GrantStatus = "active" | "expired" | "revoked";
+//# sourceMappingURL=types.d.ts.map

package/dist/pdpp/types.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../src/pdpp/types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,4EAA4E;AAC5E,eAAO,MAAM,qBAAqB,iCAAiC,CAAC;AAEpE;;;;;;;;;;;;;GAaG;AACH,eAAO,MAAM,yBAAyB,qCAAqC,CAAC;AAE5E,qCAAqC;AACrC,eAAO,MAAM,kBAAkB,UAAU,CAAC;AAE1C,6EAA6E;AAC7E,eAAO,MAAM,sBAAsB,UAAU,CAAC;AAE9C;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,gBAAgB,eAAe,CAAC;AAE7C;;;;GAIG;AACH,eAAO,MAAM,mBAAmB,yCAAyC,CAAC;AAE1E,MAAM,MAAM,UAAU,GAAG,YAAY,GAAG,YAAY,CAAC;AAErD;;;GAGG;AACH,MAAM,MAAM,UAAU,GAAG,WAAW,GAAG,iBAAiB,CAAC;AAEzD,qFAAqF;AACrF,MAAM,WAAW,aAAa;IAC5B,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAMD,MAAM,WAAW,SAAS;IACxB,kCAAkC;IAClC,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,iCAAiC;IACjC,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;GAQG;AACH,MAAM,WAAW,aAAa;IAC5B,iFAAiF;IACjF,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC;IAClB,iFAAiF;IACjF,UAAU,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC;CAC/C;AAED,MAAM,WAAW,aAAa;IAC5B,wEAAwE;IACxE,IAAI,EAAE,MAAM,CAAC;IACb,iFAAiF;IACjF,SAAS,CAAC,EAAE,UAAU,GAAG,UAAU,CAAC;IACpC,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;IACxB,UAAU,CAAC,EAAE,SAAS,CAAC;IACvB,uDAAuD;IACvD,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,6EAA6E;IAC7E,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC;IAClB,kDAAkD;IAClD,SAAS,CAAC,EAAE,MAAM,EAAE,CAAC;IACrB;;;;OAIG;IACH,OAAO,CAAC,EAAE,aAAa,CAAC;CACzB;AAED;;;GAGG;AACH,MAAM,WAAW,YAAY;IAC3B,WAAW,CAAC,EAAE,MAAM,EAAE,CAAC;CACxB;AAED,MAAM,WAAW,SAAS;IACxB,yBAAyB;IACzB,YAAY,EAAE,MAAM,CAAC;IACrB,0CAA0C;IAC1C,SAAS,EAAE,QAAQ,GAAG,WAAW,CAAC;CACnC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,WAAW,cAAc;IAC7B,gEAAgE;IAChE,EAAE,EAAE,MAAM,CAAC;IACX;;;;OAIG;IACH,OAAO,EAAE,MAAM,CAAC;IAChB,2DAA2D;IAC3D,kBAAkB,CAAC,EAAE,SAAS,EAAE,CAAC;IACjC,yDAAyD;IACzD,sBAAsB,CAAC,EAAE,MAAM,EAAE,CAAC;CACnC;AAED;;;;;GAKG;AACH,MAAM,WAAW,eAAe;IAC9B,SAAS,CAAC,EAAE,SAAS,CAAC;IACtB,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB;AAED,+DAA+D;AAC/D,MAAM,WAAW,gBAAgB;IAC/B,IAAI,EAAE,OAAO,qBAAqB,GAAG,OAAO,yBAAyB,CAAC;IACtE,2EAA2E;IAC3E,MAAM,EAAE;QAAE,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IACvB,YAAY,EAAE,MAAM,CAAC;IACrB,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,WAAW,EAAE,UAAU,CAAC;IACxB,SAAS,CAAC,EAAE,SAAS,CAAC;IACtB,0EAA0E;IAC1E,OAAO,CAAC,EAAE,aAAa,EAAE,CAAC;IAC1B,+DAA+D;IAC/D,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,aAAa,CAAC,EAAE,YAAY,CAAC;CAC9B;AAMD,MAAM,WAAW,cAAc;IAC7B,iEAAiE;IACjE,KAAK,EAAE,MAAM,CAAC;IACd,sBAAsB;IACtB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,4EAA4E;IAC5E,KAAK,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,WAAW;IAC1B,8DAA8D;IAC9D,IAAI,EAAE,MAAM,CAAC;IACb,0EAA0E;IAC1E,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB,qEAAqE;IACrE,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,eAAe,CAAC,EAAE,cAAc,CAAC;IACjC,qEAAqE;IACrE,SAAS,CAAC,EAAE,MAAM,EAAE,CAAC;CACtB;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,eAAe;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,UAAU,GAAG,UAAU,CAAC;IACnC,gFAAgF;IAChF,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,UAAU,CAAC,EAAE,SAAS,CAAC;IACvB,OAAO,CAAC,EAAE,aAAa,CAAC;CACzB;AAED,oEAAoE;AACpE,MAAM,WAAW,kBAAkB;IACjC,OAAO,EAAE,eAAe,EAAE,CAAC;IAC3B,mFAAmF;IACnF,eAAe,CAAC,EAAE,MAAM,EAAE,CAAC;CAC5B;AAED,MAAM,WAAW,KAAK;IACpB,iDAAiD;IACjD,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,MAAM,CAAC;IACjB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE;QAAE,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IACxB,MAAM,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,cAAc,CAAC,EAAE,aAAa,CAAA;KAAE,CAAC;IAC9D,uDAAuD;IACvD,MAAM,EAAE;QAAE,IAAI,EAAE,UAAU,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IACzC,+EAA+E;IAC/E,kBAAkB,EAAE;QAAE,OAAO,EAAE,MAAM,CAAA;KAAE,CAAC;IACxC,YAAY,EAAE,MAAM,CAAC;IACrB,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,WAAW,EAAE,UAAU,CAAC;IACxB,OAAO,EAAE,WAAW,EAAE,CAAC;IACvB,8DAA8D;IAC9D,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,SAAS,CAAC,EAAE,SAAS,CAAC;IACtB,8BAA8B;IAC9B,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB;;;OAGG;IACH,SAAS,CAAC,EAAE,kBAAkB,CAAC;CAChC;AAED,0DAA0D;AAC1D,wBAAgB,UAAU,CAAC,KAAK,EAAE,KAAK,GAAG,OAAO,CAEhD;AAMD;;;;;;;;;GASG;AACH,MAAM,WAAW,eAAe;IAC9B,sDAAsD;IACtD,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;;;OAIG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,cAAc;IAC7B,IAAI,EAAE,MAAM,CAAC;IACb;;;;;;OAMG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,+EAA+E;IAC/E,OAAO,CAAC,EAAE,eAAe,CAAC;IAC1B;;;;;;;;;;;OAWG;IACH,SAAS,CAAC,EAAE,eAAe,GAAG,aAAa,CAAC;IAC5C,yDAAyD;IACzD,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB;;;;OAIG;IACH,eAAe,EAAE,MAAM,EAAE,CAAC;IAC1B;;;OAGG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,8EAA8E;IAC9E,WAAW,EAAE,MAAM,EAAE,CAAC;IACtB,8EAA8E;IAC9E,MAAM,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IACjC,kFAAkF;IAClF,SAAS,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CACrC;AAED,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,EAAE,CAAC;CAClB;AAED,MAAM,WAAW,cAAc;IAC7B,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,aAAa,EAAE,CAAC;CAC1B;AAED;;;;GAIG;AACH,MAAM,WAAW,mBAAmB;IAClC,SAAS,EAAE,MAAM,CAAC;IAClB,WAAW,EAAE,UAAU,CAAC;IACxB;;;;;;OAMG;IACH,OAAO,CAAC,EAAE;QAAE,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;IAC5B,0DAA0D;IAC1D,OAAO,EAAE,MAAM,CAAC;IAChB,mFAAmF;IACnF,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,cAAc,EAAE,CAAC;IAC1B,KAAK,CAAC,EAAE,YAAY,EAAE,CAAC;IACvB,iBAAiB,CAAC,EAAE,cAAc,EAAE,CAAC;CACtC;AAMD,MAAM,MAAM,aAAa,GAAG,OAAO,GAAG,QAAQ,CAAC;AAE/C,MAAM,WAAW,uBAAuB;IACtC,IAAI,EAAE,OAAO,qBAAqB,CAAC;IACnC,MAAM,EAAE;QAAE,IAAI,EAAE,UAAU,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IACzC,YAAY,EAAE,MAAM,CAAC;IACrB,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,WAAW,EAAE,UAAU,CAAC;IACxB,OAAO,EAAE,WAAW,EAAE,CAAC;CACxB;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,0BAA0B;IACzC,IAAI,EAAE,OAAO,yBAAyB,CAAC;IACvC,KAAK,EAAE,KAAK,CAAC;CACd;AAED,2EAA2E;AAC3E,MAAM,MAAM,sBAAsB,GAChC,uBAAuB,GAAG,0BAA0B,CAAC;AAEvD;;;;GAIG;AACH,MAAM,WAAW,yBAAyB;IACxC,MAAM,EAAE,OAAO,CAAC;IAChB,eAAe,CAAC,EAAE,aAAa,CAAC;IAChC,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,uEAAuE;IACvE,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;IACxB,uEAAuE;IACvE,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,gEAAgE;IAChE,GAAG,CAAC,EAAE,MAAM,CAAC;IACb;;;;;OAKG;IACH,qBAAqB,CAAC,EAAE,sBAAsB,EAAE,CAAC;CAClD;AAED,oFAAoF;AACpF,MAAM,MAAM,cAAc,GACxB,SAAS,GAAG,SAAS,GAAG,SAAS,GAAG,eAAe,GAAG,eAAe,CAAC;AAExE;;;;GAIG;AACH,MAAM,WAAW,gBAAgB;IAC/B,MAAM,EAAE,OAAO,CAAC;IAChB,SAAS,CAAC,EAAE,aAAa,CAAC;IAC1B,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,wEAAwE;IACxE,WAAW,CAAC,EAAE,MAAM,EAAE,CAAC;IACvB,2EAA2E;IAC3E,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,2DAA2D;IAC3D,KAAK,CAAC,EAAE,KAAK,CAAC;IACd,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,cAAc,CAAC,EAAE,cAAc,CAAC;CACjC;AAED,MAAM,MAAM,WAAW,GAAG,QAAQ,GAAG,SAAS,GAAG,SAAS,CAAC"}

package/dist/pdpp/types.js

@@ -0,0 +1,61 @@
+/**
+ * PDPP Core v0.1.0 authorization types.
+ *
+ * These mirror the normative field tables in PDPP Core §6 (Selection Request)
+ * and §7 (Grant). Where this file and the spec disagree, the spec wins — §7
+ * says so explicitly about its own TypeScript mirror.
+ *
+ * The PDPP grant model is deliberately separate from the Vana chain grant in
+ * `../grants/`. That one is an EIP-712 payload binding a builder address to
+ * dot-scopes; this one is an RFC 9396 consent artifact binding an OAuth client
+ * to declaration-resolved streams. They are different authorities over
+ * different data and must not be conflated.
+ */
+/** The RFC 9396 `type` value that marks an authorization detail as PDPP. */
+export const PDPP_DATA_ACCESS_TYPE = "https://pdpp.dev/data-access";
+/**
+ * The v0.2 RFC 9396 `type`.
+ *
+ * v0.2 is deliberately a *separate* detail type rather than a compatible
+ * extension of v0.1. The revision changes authorization resolution (explicit
+ * minima) and disclosed-record semantics (a schema's `required` array is no
+ * longer a consent floor), so the two are not wire-compatible: the same
+ * request body resolves to a different grant under each. An AS implementing
+ * both MUST resolve each under its own revision, which is why every rule below
+ * branches on this constant rather than on the presence of a v0.2-only member.
+ *
+ * A client MUST NOT retry a rejected v0.2 request under the v0.1 type without
+ * a new authorization decision; nothing here silently downgrades one.
+ */
+export const PDPP_DATA_ACCESS_TYPE_V02 = "https://pdpp.dev/data-access/0.2";
+/** The v0.1 grant schema version. */
+export const PDPP_GRANT_VERSION = "0.1.0";
+/** The v0.2 grant schema version, issued for `PDPP_DATA_ACCESS_TYPE_V02`. */
+export const PDPP_GRANT_VERSION_V02 = "0.2.0";
+/**
+ * The PDPP HTTP API contract version, sent and echoed in the `PDPP-Version`
+ * header. Normative value from Core §8 "API versioning".
+ *
+ * §7 "Version layering" is explicit that the three version axes MUST NOT be
+ * conflated, and this is the one that is easiest to get wrong: it is the HTTP
+ * *contract* version, not `PDPP_GRANT_VERSION` (the grant schema, `0.1.0`) and
+ * not `source_declaration.version` (an opaque declaration revision). This
+ * previously carried the grant schema version, which meant a client pinning
+ * the spec's own header value was rejected by the AS while the RS accepted it —
+ * a client could reach only half the server.
+ *
+ * Both the AS and RS surfaces import this one constant so they cannot drift
+ * apart again.
+ */
+export const PDPP_API_VERSION = "2026-04-06";
+/**
+ * The one purpose code Core gives a protocol-level consent requirement
+ * (§6 "AI training consent"). Every other code is a structured policy
+ * declaration the AS displays but does not gate on.
+ */
+export const AI_TRAINING_PURPOSE = "https://pdpp.dev/purpose/ai_training";
+/** True for a grant issued under the v0.2 detail type. */
+export function isV02Grant(grant) {
+    return grant.version === PDPP_GRANT_VERSION_V02;
+}
+//# sourceMappingURL=types.js.map

package/dist/pdpp/types.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"types.js","sourceRoot":"","sources":["../../src/pdpp/types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,4EAA4E;AAC5E,MAAM,CAAC,MAAM,qBAAqB,GAAG,8BAA8B,CAAC;AAEpE;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,yBAAyB,GAAG,kCAAkC,CAAC;AAE5E,qCAAqC;AACrC,MAAM,CAAC,MAAM,kBAAkB,GAAG,OAAO,CAAC;AAE1C,6EAA6E;AAC7E,MAAM,CAAC,MAAM,sBAAsB,GAAG,OAAO,CAAC;AAE9C;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAG,YAAY,CAAC;AAE7C;;;;GAIG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,sCAAsC,CAAC;AA0N1E,0DAA0D;AAC1D,MAAM,UAAU,UAAU,CAAC,KAAY;IACrC,OAAO,KAAK,CAAC,OAAO,KAAK,sBAAsB,CAAC;AAClD,CAAC"}

package/dist/pdpp-version.d.ts

@@ -0,0 +1,28 @@
+/**
+ * The single `PDPP-Version` value both the Authorization Server and Resource
+ * Server surfaces of this Personal Server negotiate against (spec-core.md
+ * §8 "API versioning").
+ *
+ * Spec-core.md's own normative example is a date string
+ * (`PDPP-Version: 2026-04-06`), not a semver string — this constant follows
+ * that convention. Both AS and RS route modules MUST import this one
+ * constant rather than declaring their own local copy: an AS and RS that
+ * hard-reject an unrecognized `PDPP-Version` (spec §8 requires this) but
+ * accept mutually exclusive values make half the server unreachable to any
+ * client that pins a version header.
+ *
+ * Found in an independent combined AS+RS review (2026-09-17): the AS lane's
+ * `packages/core/src/pdpp/types.ts` previously declared its own
+ * `PDPP_API_VERSION = "0.1.0"` (a semver-shaped grant/API contract version,
+ * not the spec's `PDPP-Version` header value) alongside this module's
+ * `PDPP-Version = "2026-04-06"` in the RS route files. A client sending
+ * either header value could reach only one half of the server. Fix: one
+ * shared constant, spec-date-shaped, imported by both surfaces. The AS lane
+ * needs to adopt this constant (or reconcile `PDPP_API_VERSION`'s meaning to
+ * something distinct from the `PDPP-Version` header, if that field is
+ * actually meant to version the grant schema rather than the wire protocol)
+ * — that reconciliation was not made unilaterally here since it touches
+ * AS-owned files this lane does not edit.
+ */
+export declare const PDPP_VERSION = "2026-04-06";
+//# sourceMappingURL=pdpp-version.d.ts.map

package/dist/pdpp-version.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pdpp-version.d.ts","sourceRoot":"","sources":["../src/pdpp-version.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,YAAY,eAAe,CAAC"}

package/dist/pdpp-version.js

@@ -0,0 +1,28 @@
+/**
+ * The single `PDPP-Version` value both the Authorization Server and Resource
+ * Server surfaces of this Personal Server negotiate against (spec-core.md
+ * §8 "API versioning").
+ *
+ * Spec-core.md's own normative example is a date string
+ * (`PDPP-Version: 2026-04-06`), not a semver string — this constant follows
+ * that convention. Both AS and RS route modules MUST import this one
+ * constant rather than declaring their own local copy: an AS and RS that
+ * hard-reject an unrecognized `PDPP-Version` (spec §8 requires this) but
+ * accept mutually exclusive values make half the server unreachable to any
+ * client that pins a version header.
+ *
+ * Found in an independent combined AS+RS review (2026-09-17): the AS lane's
+ * `packages/core/src/pdpp/types.ts` previously declared its own
+ * `PDPP_API_VERSION = "0.1.0"` (a semver-shaped grant/API contract version,
+ * not the spec's `PDPP-Version` header value) alongside this module's
+ * `PDPP-Version = "2026-04-06"` in the RS route files. A client sending
+ * either header value could reach only one half of the server. Fix: one
+ * shared constant, spec-date-shaped, imported by both surfaces. The AS lane
+ * needs to adopt this constant (or reconcile `PDPP_API_VERSION`'s meaning to
+ * something distinct from the `PDPP-Version` header, if that field is
+ * actually meant to version the grant schema rather than the wire protocol)
+ * — that reconciliation was not made unilaterally here since it touches
+ * AS-owned files this lane does not edit.
+ */
+export const PDPP_VERSION = "2026-04-06";
+//# sourceMappingURL=pdpp-version.js.map

package/dist/pdpp-version.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"pdpp-version.js","sourceRoot":"","sources":["../src/pdpp-version.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG,YAAY,CAAC"}

package/dist/policy/data-read.d.ts

@@ -1,5 +1,6 @@
 import type { GatewayGrantResponse } from "@opendatalabs/vana-sdk/browser";
 import { type AuthSessionVerifierPort, type GrantListerPort, type GrantVerifierPort, type RuntimeAvailabilityPort } from "../ports/index.js";
+import type { PdppGrantBindingStore } from "../grants/pdpp-binding-store.js";
 export interface DataReadPolicyInput {
     signer: `0x${string}`;
     grantId?: string;
@@ -12,10 +13,33 @@ export interface DataReadPolicyInput {
      * owner; the check also fails closed at runtime for untyped/JS callers.
      */
     serverOwner: `0x${string}`;
+    /**
+     * The PDPP grant id the caller is reading under, when the read is authorized
+     * through a PDPP grant rather than a bare chain grant (§6).
+     *
+     * Optional because the chain-grant read path predates PDPP and still works
+     * on its own. When present — and only then — the PDPP↔chain binding is
+     * enforced in addition to every existing check, never instead of one.
+     */
+    pdppGrantId?: string;
 }
 export interface DataReadPolicyPorts {
     authSessionVerifier: AuthSessionVerifierPort;
     grantVerifier: GrantVerifierPort;
+    /**
+     * Retained PDPP↔chain grant bindings. Required only to serve reads that
+     * present a `pdppGrantId`; a PS with no PDPP surface omits it.
+     */
+    pdppGrantBindings?: PdppGrantBindingStore;
+    /**
+     * The chain deployment this PS is configured against. Required alongside
+     * `pdppGrantBindings` so a binding recorded on one network cannot authorize
+     * a read on another.
+     */
+    chainDeployment?: {
+        chainId: number;
+        contractAddress: `0x${string}`;
+    };
     runtimeAvailability?: RuntimeAvailabilityPort;
 }
 /**

package/dist/policy/data-read.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"data-read.d.ts","sourceRoot":"","sources":["../../src/policy/data-read.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAEV,oBAAoB,EACrB,MAAM,gCAAgC,CAAC;AAcxC,OAAO,EACL,KAAK,uBAAuB,EAC5B,KAAK,eAAe,EACpB,KAAK,iBAAiB,EACtB,KAAK,uBAAuB,EAC7B,MAAM,mBAAmB,CAAC;AAE3B,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,KAAK,MAAM,EAAE,CAAC;IACtB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,cAAc,EAAE,MAAM,CAAC;IAGvB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,WAAW,EAAE,KAAK,MAAM,EAAE,CAAC;CAC5B;AAED,MAAM,WAAW,mBAAmB;IAClC,mBAAmB,EAAE,uBAAuB,CAAC;IAC7C,aAAa,EAAE,iBAAiB,CAAC;IAKjC,mBAAmB,CAAC,EAAE,uBAAuB,CAAC;CAC/C;AAED;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAUxE;AAED,mEAAmE;AACnE,eAAO,MAAM,kBAAkB,aAAsC,CAAC;AAEtE,wBAAsB,oBAAoB,CACxC,KAAK,EAAE,mBAAmB,EAC1B,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAqC/B;AA0HD,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,KAAK,MAAM,EAAE,CAAC;IACtB,kEAAkE;IAClE,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,WAAW,EAAE,KAAK,MAAM,EAAE,CAAC;CAC5B;AAED,MAAM,WAAW,mBAAoB,SAAQ,mBAAmB;IAC9D;;;OAGG;IACH,WAAW,CAAC,EAAE,eAAe,CAAC;CAC/B;AAED;;;;;;;;;;;;GAYG;AACH,wBAAsB,0BAA0B,CAC9C,KAAK,EAAE,mBAAmB,EAC1B,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,MAAM,EAAE,CAAC,CAqDnB"}
+{"version":3,"file":"data-read.d.ts","sourceRoot":"","sources":["../../src/policy/data-read.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAEV,oBAAoB,EACrB,MAAM,gCAAgC,CAAC;AAcxC,OAAO,EACL,KAAK,uBAAuB,EAC5B,KAAK,eAAe,EACpB,KAAK,iBAAiB,EACtB,KAAK,uBAAuB,EAC7B,MAAM,mBAAmB,CAAC;AAE3B,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,iCAAiC,CAAC;AAE7E,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,KAAK,MAAM,EAAE,CAAC;IACtB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,cAAc,EAAE,MAAM,CAAC;IAGvB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,WAAW,EAAE,KAAK,MAAM,EAAE,CAAC;IAC3B;;;;;;;OAOG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;CACtB;AAED,MAAM,WAAW,mBAAmB;IAClC,mBAAmB,EAAE,uBAAuB,CAAC;IAC7C,aAAa,EAAE,iBAAiB,CAAC;IACjC;;;OAGG;IACH,iBAAiB,CAAC,EAAE,qBAAqB,CAAC;IAC1C;;;;OAIG;IACH,eAAe,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,eAAe,EAAE,KAAK,MAAM,EAAE,CAAA;KAAE,CAAC;IAKtE,mBAAmB,CAAC,EAAE,uBAAuB,CAAC;CAC/C;AAED;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAUxE;AAED,mEAAmE;AACnE,eAAO,MAAM,kBAAkB,aAAsC,CAAC;AAEtE,wBAAsB,oBAAoB,CACxC,KAAK,EAAE,mBAAmB,EAC1B,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAgG/B;AA0HD,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,KAAK,MAAM,EAAE,CAAC;IACtB,kEAAkE;IAClE,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,WAAW,EAAE,KAAK,MAAM,EAAE,CAAC;CAC5B;AAED,MAAM,WAAW,mBAAoB,SAAQ,mBAAmB;IAC9D;;;OAGG;IACH,WAAW,CAAC,EAAE,eAAe,CAAC;CAC/B;AAED;;;;;;;;;;;;GAYG;AACH,wBAAsB,0BAA0B,CAC9C,KAAK,EAAE,mBAAmB,EAC1B,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,MAAM,EAAE,CAAC,CAuDnB"}