Credential product-category scope is accepted but never enforced

[LKSNDRTMLKV]

DppCredentialSubject carries product_categories: Vec<String>, and core will enforce it — verify_credential_claims_with_trust takes a required_product_category and applies the same "empty means unscoped, populated must contain" rule it applies to sectors.

The engine passes None. So a credential scoped to one product category grants its full audience over every product in a sector it covers.

Why it was left unenforced

This is a deliberate non-implementation, not an oversight, and it should not be "fixed" by wiring the obvious thing.

There is no defined mapping between the credential's free-string product_categories and the typed dpp_domain::ProductCategory a passport carries. ProductCategory is a #[non_exhaustive] enum with rename_all = "snake_case" plus an Other(String) variant, so:

• unit variants serialise as "ev_battery", "apparel", "smartphone"
• Other(s) serialises as {"other": s} — an object, not a string

There is no round-trippable &str form today. Enforcing scope would mean inventing a correspondence and then relying on it as a security control: get it wrong in the permissive direction and the check silently passes everything; wrong in the restrictive direction and lawful holders are denied. Neither failure is visible without a spec to test against.

Sector scope is enforced (VerifiedCredential::audience_for_sector), and sector is the dispatch key that selects schema and plugin. Product category is a data attribute within a sector, so the unenforced axis is the narrower one.

What closing it needs

1. A core decision on the canonical wire form of a product category — most likely a ProductCategory::as_wire_str()/from_wire_str() pair with Other(s) mapping to s itself, and a documented rule for collisions between an Other string and a future unit variant. This is the actual blocker and it belongs in dpp-core.
2. Thread it through VerifiedCredential::audience_for_sector → something like audience_for(sector, product_category), passing required_product_category to core.
3. Decide the same question sector scope already answered: out-of-scope is a downgrade to Audience::Public, not a denial. A credential that does not cover this product is valid, it simply unlocks nothing here — and denying would make the route a probe for a passport's category.
4. Tests mirroring the sector ones in crates/dpp-vault/src/middleware/credential.rs: in-scope grants, out-of-scope downgrades, empty list stays unscoped, and an Other(_) category round-trips.

Where it is recorded

Named in the module docs at crates/dpp-vault/src/handlers/audience_read.rs and on VerifiedCredential::audience_for_sector, both of which record it as deliberately not built.

Introduced alongside #63.

[LKSNDRTMLKV]

Three decisions, so the blocker is a scheduling question rather than an open one

Re-verified against the current tree on 2026-07-31. The gap is real and unchanged: crates/dpp-vault/src/middleware/credential.rs:141 passes a literal None for required_product_category, so a credential scoped to one category grants its full audience over every product in a sector it covers.

The blocker was never the wiring — it is that ProductCategory has no round-trippable string form, and inventing one silently would make a security control out of a guess. ProductCategory currently has no impl block at all. Unit variants serialise as bare strings ("ev_battery", asserted by an existing passport test), while Other(s) serialises as {"other": s} — an object.

1. Other(s) maps to s, and a collision with a unit variant is equality — deliberately

The obvious worry is that Other("ev_battery") and EvBattery would produce the same wire value. Collapsing them is the correct behaviour, not a hazard to guard against.

The reason is migration. The moment a category is promoted from Other("ev_battery") to a modelled EvBattery variant, every credential and passport written before the promotion must still compare equal to ones written after. If Other(s) maps to s, they do. Treating the collision as an error would make promoting a category a breaking change for every credential already issued — the same trap the open sector axis exists to avoid.

This wants documenting on the conversion itself, not just here, because it looks like an oversight to anyone reading it cold.

2. Out of scope downgrades to Audience::Public; it never denies

Matching what sector scope already does, for a reason worth stating explicitly: denying would turn the endpoint into a probe for a passport's product category. A caller could learn the category by watching a 403 flip to a 200. Downgrading leaks nothing — the credential is valid, it simply unlocks nothing here.

3. The wire form belongs on ProductCategory in the core library

Next to the type it describes, so a second consumer cannot invent a different correspondence. Shape is as_wire_str() / from_wire_str().

Deliberately not implementing it yet

The library's contribution guidance rules out speculative public API, and a wire-form helper with no caller is exactly that. It should land in the same change that threads it through audience_for_sector → audience_for(sector, product_category) and adds the four tests this issue already lists — in-scope grants, out-of-scope downgrades, empty stays unscoped, Other(_) round-trips.

Severity, stated plainly

Not urgent, and it should not be quietly dropped either. Sector scope is enforced and sector is the broader axis — it selects schema and plugin. Product category is the narrower one, and exploiting the gap requires an issued credential in the first place. But a field that looks like an access control and is not one is worse than no field, so the honest options are to enforce it or to stop accepting it.

[LKSNDRTMLKV]

Scoping note, so this is not picked up in isolation.

The blocker recorded above — a core decision on the canonical wire form of a product category — is the same question a planned refactor of how product categories are modelled and used will have to answer. ProductCategory currently has no round-trippable &str form (non_exhaustive, rename_all = \\snake_case\\, plus Other(String) serialising as an object rather than a string), and that is exactly what makes enforcing this scope a guess in either the permissive or restrictive direction.

So this should be closed by that refactor rather than before it: wiring an invented correspondence now would make a security control depend on a mapping the refactor is likely to change.

Not a release blocker in the meantime — sector scope is enforced, and sector is the dispatch key that selects schema and plugin; product category is the narrower axis within it.