Skip to content

docs: correct the access-control model against the primary text - #10

Open
LKSNDRTMLKV wants to merge 2 commits into
mainfrom
docs/access-control-primary-text
Open

docs: correct the access-control model against the primary text#10
LKSNDRTMLKV wants to merge 2 commits into
mainfrom
docs/access-control-primary-text

Conversation

@LKSNDRTMLKV

@LKSNDRTMLKV LKSNDRTMLKV commented Jul 28, 2026

Copy link
Copy Markdown
Member

Corrects the ESPR access-control model against the primary text, and publishes the trust page.

The docs asserted that "ESPR Article 10 establishes that a Digital Product Passport carries three categories of information with different access rules" and that "an implementation that does not enforce them is not compliant."

Article 10 is titled "Requirements for the digital product passport" and establishes no access categories. The access provision is Art. 11(b) — free-of-charge access "based on their respective access rights set out in the applicable delegated act" — with the actor-to-data mapping delegated per product group under Art. 9(2)(f). ESPR names roughly fourteen actor classes and assigns them nothing.

The page also described a mechanism named after code that no longer exists: an AccessTier enum and an X-Access-Tier header. The model is audiences and disclosure classes, and a caller-supplied tier header is now deliberately ignored.

An ordered public→restricted→private scale cannot express the one fully specified model in the regime — the Battery Regulation's Art. 77(2) lattice, where one class is authority-only and another is legitimate-interest-only. That is why the code separates the two vocabularies, and the page now says so.

Also in this PR

Publishes trust.astro, which was written and never routed.

Adds a scan-telemetry disclosure to it. The node records that a passport was resolved, and no published page said so. The posture in the code is good and survives publication: aggregates are keyed by passport and day with no column for anything about the scanner, and QR renders are counted separately and never summed with scans — a render measures label production, not people. The defect was the silence, not the behaviour. Text verified against dpp-types/src/scan.rs before publishing.

Note the merge order: this touches trust.astro, and so does the i18n branch. Land this first and rebase that onto it.

ESPR Article 10 is Requirements for the digital product passport and defines no tiers; access is Art. 11(b), free of charge, with the actor-to-data mapping delegated per product group under Art. 9(2)(f) and no such act adopted yet, so the public Public/Restricted/Private tier page was wrong at its premise and is replaced by the Battery Art. 77(2) lattice plus the constraints common to every regime.
…ate per-passport-per-day count with no scanner-identifying field
@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Aug 20, 2026

Copy link
Copy Markdown

Deploying odal-node-landing with  Cloudflare Pages  Cloudflare Pages

Latest commit: 44bd73f
Status: ✅  Deploy successful!
Preview URL: https://bb594dfc.odal-node-landing.pages.dev
Branch Preview URL: https://docs-access-control-primary.odal-node-landing.pages.dev

View logs

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying odal-node-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 44bd73f
Status: ✅  Deploy successful!
Preview URL: https://4d143739.odal-node-docs.pages.dev
Branch Preview URL: https://docs-access-control-primary.odal-node-docs.pages.dev

View logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant