spec: display and record client terms links, and relate Core to the agreement standards

[tnunamak]

Someone approving a grant — the permanent record of consent by which a person lets a company keep reading their personal data — hands that company ongoing access. Today the protocol does not require that the person be shown the company's privacy policy or terms of service before they agree, and it keeps no record of whether they were. If they later dispute what the company did with their data, neither side can establish which terms were on screen at the moment of approval. This PR closes that. It also states, for the first time, how PDPP relates to the standards that govern agreements and consent records — and fixes a factual error about one of them that was steering our thinking.

The protocol is PDPP, an authorization protocol for personal data: an owner (the person) issues a grant letting a client (an app or company) read specific data from a source. The authorization server, abbreviated AS in the tables below, is the component that runs the consent screen and issues grants. Throughout, Core means spec-core.md, the normative document defining the protocol, as opposed to the reference implementation — the working Node and Postgres codebase in this repository. This PR edits only the first of those two. v0.1 is the protocol version Core currently specifies and the one this PR targets.

1. Client terms and privacy policy

Core carries the requesting application's privacy-policy and terms links as policy_uri and tos_uri, two field names Core borrows from RFC 7591, the OAuth specification that defines the standard vocabulary for describing a client application. Two things were wrong with how Core handled them.

The display rule was weaker than its own source. Core said the authorization server "MAY display them as secondary links." RFC 7591 Section 2 says of each field that "the authorization server SHOULD display this URL to the end-user if it is provided." Core cites that vocabulary and then states a weaker obligation than it carries, which reads as a drafting slip rather than a decision. This raises Core to SHOULD, matching the source.

Nothing recorded what was shown. The grant is meant to be the durable artifact of consent, but it never had to say which policy and terms links the owner was shown. This makes recording mandatory where the links were displayed. It needs no new field, because the grant's field definitions in Core already include an optional client_display object — the requester information the server resolved and can vouch for, written as client.client_display where the full path matters, since it sits inside the grant's client object — and policy_uri and tos_uri are already listed among its members. Populating them was simply never required. The rule also forbids recording a value the server resolved but did not display, so the grant records the consent surface rather than the server's internal lookup.

The evidence this produces is deliberately bounded, and the spec text now says so. A recorded URI shows which documents the owner was pointed at, not what those documents said, because the target belongs to the client and can change after the grant is issued. ISO/IEC 29184:2020 — the ISO standard on online privacy notices and consent — sets the stronger bar in Section 5.2.8: an organization "shall keep and make available the version of the notice presented when the PII principal gave consent." Core points deployments at that as a SHOULD rather than mandating it, because retaining the version means the authorization server must fetch and store third-party documents. That is a real deployment cost and a new outbound-fetch surface, and neither is an authorization semantic.

Finally, a client requesting the ai_training purpose — one of the values of purpose_code, the field stating what the data will be used for — must now have a policy_uri in its resolved metadata, and the server must reject the request otherwise. Core already singles this purpose out: its registry entry and its "AI training consent" subsection both state that the server must obtain explicit affirmative consent before issuing such a grant, and call it "the sole purpose code with a mandatory consent requirement at the protocol level," where every other purpose code's consent properties are advisory. Consent to training is not informed if there is nowhere to read how the recipient handles the data, so this attaches the policy link to the one purpose Core has already decided is different. The requirement falls on resolved metadata rather than on the inline request, so a client the server already knows through registration does not have to resend it.

Decision row — client terms and privacy policy

Proposed text	AS SHOULD display policy_uri/tos_uri when present; MUST record the exact displayed values in the grant's client.client_display; MUST NOT record a resolved-but-undisplayed value as displayed; SHOULD (not MUST) retain a snapshot or digest; ai_training requests MUST have a resolved policy_uri.
Strongest alternative	Require a content snapshot or digest — a stored copy of the documents, or a hash of them — rather than just the URI. This is what ISO/IEC 29184 and Kantara actually require, and it is the only version that delivers "show what the user saw." Kept as a SHOULD for the fetch-and-store cost given above. A weaker alternative — record nothing, leave it to deployments — was rejected because the grant is already the consent artifact and the marginal cost of populating an existing field is zero.
Confidence	Confidence differs sharply across the three parts, so they are worth reviewing separately rather than as one change. SHOULD-display realignment: near-certain — it restores the exact keyword of the RFC that Core cites as its source, so the only way it is wrong is if Core meant to diverge and never said so. Recording obligation: fairly confident — the concept is well-precedented in the consent-receipt standards — ISO/IEC 29184, the ISO standard on online privacy notices, and the Kantara Consent Receipt, an industry format for a machine-readable record of a consent event — but it has no precedent in the OAuth or OpenID Connect family, so it is a genuine extension of that lineage and a reviewer may reasonably want it argued rather than assumed. ai_training policy_uri rule: least confident, and the one most worth pushing back on — no regime I could find names AI training as a trigger for a heightened privacy-policy requirement, so it rests entirely on Core's own prior decision to treat that purpose differently, not on outside prior art.

Prior art below, one row per standard, including the ones that turned out to have no opinion — a standard that is silent on a question is as useful to know about as one that answers it. Each row names what the standard is, since they come from several unrelated fields.

Standard (what it is)	Opinion on display?	Opinion on recording what was displayed?	Strength
RFC 7591 §2 — the OAuth spec defining client metadata fields	Yes	No — zero mentions on full-text search	SHOULD display
OIDC Dynamic Client Registration 1.0 §2 — the OpenID Connect equivalent of RFC 7591	Yes, copies RFC 7591 nearly verbatim	No	SHOULD display
OIDC Core 1.0 §3.1.2.1/.4 — the base OpenID Connect identity-login spec	Consent generally, not these fields	No	SHOULD prompt; MUST obtain a decision
OpenID Foundation certification — the conformance programme that tests OpenID implementations	No	No	— (searched, confirmed absent)
Google Play Prominent Disclosure — Google's Android app-store policy	Yes, and at the moment of the request	No	Must immediately precede the data request
Apple App Store Review Guidelines 5.1.1(i) — Apple's iOS app-store policy	Yes, but in the listing and app, not at consent	No	Must be linked "in an easily accessible manner"
UK Open Banking Customer Experience Guidelines — the UK regulator-backed rules for bank consent screens	Yes (which data, what purpose)	Not found in the pages I checked	Mandatory for data clusters; terms pattern unverified
FDX Consent API — Financial Data Exchange, the US/Canadian banking data-sharing standards body	Unverified — its specification is access-gated	Unverified	Cannot assess
GDPR Art. 13 — EU law's list of what a controller must tell people	No — enumerates required content, never names a policy or terms document	No	Binding law
GDPR Art. 7(1) — EU law's consent-proof duty	No	Indirect — must show consent occurred, not what was shown	"shall be able to demonstrate"
EDPB Guidelines 05/2020 ¶108 — the EU regulators' joint guidance on consent	No	Yes — retain "a copy of the information that was presented"	Illustrative ("could"), not binding
W3C DPV 2.3 — the Data Privacy Vocabulary, a shared set of terms for describing consent	No — a vocabulary, not a behavioural mandate	Yes, structurally: a consent record points at a notice object, not a bare URL	Vocabulary only
Kantara Consent Receipt v1.1.0 §4.4.10 — an industry format for a machine-readable consent receipt	Implicit	Yes — policyURL REQUIRED, pinned to the policy "in effect when the consent was obtained"	REQUIRED field
ISO/IEC 29184:2020 §5.2.8 — the ISO standard on online privacy notices and consent	No new opinion	Yes — the strongest found anywhere	Normative "shall keep... the version of the notice presented"

One pattern in that table is worth naming because it changes how the recording rule should be reviewed: display obligations and recording obligations sit in entirely different families of standard. Nothing in the OAuth or OpenID Connect lineage requires persisting what was displayed. So this is an extension of that lineage rather than a gap-fill, and it deserves to be argued on its merits rather than waved through as "aligning with OAuth."

2. MyTerms (IEEE 7012), and how Core relates to the agreement standards

spec-deferred.md — the companion document listing concerns deliberately left out of scope for v0.1, so a future version can pick them up — called this prior art "ISO MyTerms" and said it "has not been evaluated for fit." Both parts were a problem. It is not an ISO standard: it is IEEE 7012-2025, "Standard for Machine Readable Personal Privacy Terms," published in January 2026. The wrong name sends a reader looking for something that does not exist, and it obscured that the standard is published rather than a draft we could defer thinking about. Leaving it unevaluated also left open the question this PR was asked to settle: whether PDPP is quietly drifting toward incompatibility with it.

MyTerms inverts the usual direction of an online agreement: the individual is the first party and offers privacy terms, and the service provider is the second party that accepts one. Terms are not written per relationship — they are chosen from a roster kept by a neutral non-business entity, today Customer Commons, where each term is a versioned URL you can fetch.

What this PR does and does not add. Two options were on the table. The wider one would have added an optional agreement object to the grant now, to hold a reference to a rostered term. A prior-art survey recommended it; a separate reviewer, working from that survey and not involved in writing it, recommended against, and this PR follows the reviewer. Take the score attached to that recommendation as one reader's stated strength of opinion rather than a measurement — what should carry weight here is the argument, which is checkable and is this.

The case for adding the field early rested on RFC 9396 Section 5. RFC 9396 is the OAuth extension PDPP uses to carry a structured request, and its Section 5 says an authorization server must reject a request object of a known type that carries fields the server does not recognise. The survey read that as meaning a terms field would be expensive to retrofit, so better to add it now. But Section 5 constrains what a client sends in a request, and the proposed agreement object lived only on the grant the server issues afterwards. Section 5 therefore neither blocks nor eases it, and the urgency does not survive the distinction. What remains is that no client publishes accepted terms today, no surface exists to publish them on, and no acceptance step exists — so adding the field now would fix the shape of a record before the flow that produces it exists. This PR adds no field.

What it adds instead is precision about where PDPP stands. Three rows in Core's "Relationship to existing standards" table, chosen against a deliberate test: a row earns its place only if it explains something the spec does today, or names a bar the spec is measured against. Adjacent-and-interesting is not enough — that is table weight with no reader benefit.

• ISO/IEC 29184:2020 — the ISO standard on online privacy notices and consent — kept as already written, because it is the citation that explains why a recorded URI is weaker evidence than a retained version. It explains a rule Core now carries.
• ISO/IEC TS 27560:2023 — the technical specification for consent-record structure — named as a deferred export mapping, since a PDPP grant already carries most of that structure. The row is careful on one point: PDPP records a reference to the notice shown only where a link was actually displayed, so it does not claim every grant carries 27560's mandatory notice field. This row also names the W3C Data Privacy Vocabulary (DPV), the shared vocabulary such a mapping would be expressed in, noting that DPV keeps purpose, consent, and the consent record as distinct classes the way PDPP does, that its consent record points at a notice object rather than a bare URL, and that DPV is a Community Group report and explicitly not a W3C standard.
• IEEE 7012-2025 (MyTerms) — two sentences, no more: the individual proffers terms as the first party and both sides keep a matching record, and a PDPP grant records an authorization rather than an agreement and could later reference one. It deliberately stops short of calling every grant an agreement record, which would overstate what the grant is. It stays in the table at that size because the question it answers came from workshop feedback, so a reader will look for it.

Two candidate rows were cut. W3C ODRL 2.2, a general language for expressing permissions, describes no current PDPP surface and the mapping to it is speculative. A separate DPV row was written and then folded into the 27560 row above: DPV describes nothing Core does today, so it is a detail of the deferred mapping rather than a relationship in its own right. Cutting the row keeps the substance and drops the weight.

One correction worth recording, because it went the other way. An earlier draft of this work described DPV's extension for IEEE 7012 as stranded at an old version. That was wrong: it ships in DPV 2.3 as STANDARD-IEEE-7012, which I verified against the DPV specification directly.

Separately, the UMA 2.0 row gains one clause noting that UMA places the resource owner's policy outside its own scope — which is why PDPP's structured commitments are an addition rather than a divergence from it.

The design the deferred entry now records. The entry previously offered purpose_code — the field naming what the data will be used for — as the way to reference a rostered term. That is removed, and the entry now warns against it: an agreement URI is a syntactically valid purpose code, so the route is legal and still wrong, because purpose and agreement are separate objects in every standard surveyed and the ai_training rule switches on the purpose code's value. In its place the entry records the two-sided design a future version should implement, because a one-sided record is exactly what MyTerms rejects. The client publishes, in its client metadata document, the rostered terms it accepts. The authorization server holds the rostered term the owner chose. At grant time the server matches the two mechanically, with no negotiation round trip. The grant records the matched term — URI, version, acceptance time — in a future optional agreement object, echoed back through introspection, the authenticated call a resource server makes to ask the authorization server what a token actually authorizes. PDPP defines no terms vocabulary of its own, now or later; that is the thing that would actually create incompatibility with a roster-based standard.

The entry also records why the request side is the half that needs a version to land in. Because of RFC 9396 Section 5, a client cannot start sending a terms field early and have servers ignore it — the server must reject the whole request. So a request-side carrier has to be defined inside authorization_details, the structured object a client sends to describe what it is asking for, under PDPP's own type name for it. The grant-side and metadata-side halves carry no such constraint. This is the same rule that failed to justify adding a field today, applied to the thing it actually governs.

Decision row — MyTerms compatibility

Proposed text	Three relationship rows in Core (ISO/IEC 29184, ISO/IEC TS 27560 with DPV named inside it, IEEE 7012) plus one added UMA clause; no new protocol field. In spec-deferred.md: fix the name to IEEE 7012, drop the purpose_code route and warn against it, and record the two-sided publish-hold-match-record design for a future version.
Strongest alternative	Add the optional grant-level agreement object now (term URI, version, proffering party, acceptance time, optional digest). This was the prior-art survey's own recommendation, on the argument that an optional field is cheaper added now than later, because the grant carries a schema version fixed at 0.1.0 that resource servers must reject if they do not support it — so a field added afterwards arrives as a version change rather than a quiet addition. Rejected on review: the RFC 9396 §5 argument for urgency does not apply to a grant-side field, and no producing flow exists to exercise the shape. A third option — say nothing beyond citations — was rejected because it leaves the standards relationship unstated, which is what was asked for.
Confidence	The name correction is not in doubt — IEEE's own page gives the title, status and publication date. The DPV extension status is verified directly, which matters because the claim being corrected was wrong in the other direction. The relationship rows are stated at the strength the evidence supports and no more: they claim referenceability and a deferred mapping, never conformance. Which rows belong is a judgement call, and the weight test is the reviewable part of it — if you think DPV or ODRL earns a row of its own, that is the disagreement to have. The deferred design is a recorded intention, not a commitment — the roster is small, no client publishes accepted terms today, and if that stays true the design stays deferred at no cost.

Two findings from the wider survey are worth stating because they bound what any future design can rely on. No OAuth-family standard models owner-proffered terms at all — UMA 2.0 examined the question and put the resource owner's policy outside its scope, and GNAP (RFC 9635, the IETF's redesign of delegation) mentions privacy policies and terms of service zero times. So there is no existing pattern to follow here, which is a reason to move slowly rather than a reason to move first. And IEEE 7012 defines no wire format, being deliberately protocol-agnostic, so "conformance" has no testable protocol-layer meaning today even if we wanted to claim it — which is why the IEEE row claims referenceability instead.

What I have not verified

The reference implementation — this repository's working codebase, as distinct from Core the specification — is untouched. Its consent card, the component that draws the approval screen (at packages/operator-ui/src/components/pdpp/consent-card.tsx), renders neither the privacy-policy nor the terms link today; I checked. So the new SHOULD-display rule describes work that surface has not done yet, and this PR neither does that work nor adds a conformance test for it. A reviewer who wants the specification and the code to move together should ask for that follow-up.

Two prior-art rows stayed unverified against primary sources and are marked as such above rather than quietly dropped: UK Open Banking's terms-and-conditions display pattern (found as guidance, exact mandatory clause not confirmed) and FDX's Consent API schema (primary specification is access-gated; only a press release describing "consent traceability" was reachable). Neither is load-bearing for the proposal.

The ISO/IEC TS 27560 row rests on a second-hand reading. That specification's normative text is paywalled; its structure was read through W3C DPV's published mapping guide rather than the ISO document. The row is written to survive that: it names the four sections and defers the mapping to a companion document, and makes no claim about any individual clause. Anyone writing the actual mapping should buy the specification first. The ISO/IEC 29184 quotation is stronger — I extracted it from the standard's own preview PDF — but it is still a preview rather than the full document.

IEEE 7012-2025's normative text is also unread, being behind IEEE's paywall. The relationship row is drawn from the standard's free project page, which is sufficient for stating a relationship and would not be sufficient for a conformance claim. The row makes no conformance claim, deliberately.

I did not find any regime that names AI training as a purpose triggering a heightened privacy-policy requirement. That rule therefore rests on Core's own existing decision to single out ai_training, not on outside precedent, which is why its confidence is the lowest of the three.

The same wrong "ISO MyTerms" name appears twice in docs/community/working-sessions/2026-08-20-session-3-grants-resource-server.md. I left those deliberately: that file is a dated record of what was said in a room, not a statement of fact about the standard. Reviewers who disagree should say so and I will correct them.

Verification

Rebased onto origin/main. All three spec gates pass.

pnpm spec:check regenerates the specification pages served on the project's public documentation site from these root spec-*.md files and fails if the two ever disagree. Passing it proves the edits propagate cleanly to the published pages; it says nothing about whether the prose is correct, which is what review is for.

pnpm spec:dates fails when a spec's declared date is older than its last substantive commit. It now passes on all ten specs. An earlier revision of this PR reported one failure here on a file this branch does not touch; that was fixed on main and the rebase picked it up.

The spec prose gate — a linter added to main after this branch's first commits, which flags over-long sentences and similar issues against published style authorities — reports no new findings. That gate is a ratchet: it builds a baseline from the changed files as they stood at the merge base and blocks only on findings this branch introduces, so pre-existing prose is waived and new prose is not. Reproducing it locally the way CI does surfaced four over-long sentences that this branch had itself introduced before the gate existed, in its earlier commits; those are rewritten here, which is why the diff touches a few lines neither decision above otherwise required.

On sourcing: the ISO/IEC 29184 Section 5.2.8 wording quoted in the spec text was extracted from that standard's own preview PDF rather than taken from a secondary summary, and the DPV extension status was checked against the DPV specification itself. Both are cited in the spec rows so a reviewer can re-check them from the text alone, without needing anything outside this repository.

Assisted-by: AI

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pdpp	Ready	Preview	Sep 3, 2026 10:40pm UTC