Policy config: add client PD block (4078-1)

[stevenvegt]

Parent PRD

#4078

Summary

First foundational PR of the #4078 chain. The policy config loader now recognizes an optional service_provider PresentationDefinition per credential profile, alongside the existing organization and user. Loaded service_provider PDs are exposed through the existing WalletOwnerMapping under a new WalletOwnerServiceProvider key so consumers added in PR #4227 can pick them up without touching the loader again. No production consumer reads the new key in this PR.

What changed

• vcr/pe/policy.go — added WalletOwnerServiceProvider = WalletOwnerType("service_provider") next to the existing WalletOwnerOrganization/WalletOwnerUser constants.
• policy/local.go — added a ServiceProvider *validatingPresentationDefinition field on credentialProfileConfig, threaded it through toWalletOwnerMapping(), and relaxed the load-time check from "at least one of organization or user" to "at least one of organization, service_provider, or user". The new field uses the same validating type as its siblings, so PE schema validation runs on unmarshal.
• policy/local_test.go — folded the new scenarios into TestStore_LoadFromFile: org-only loading now asserts service_provider is absent from the mapping (covers the unchanged-behavior bullet); new subtests cover combined org+service_provider+user loading, service-provider-only loading, malformed-service-provider rejection, and the new "no PD defined" branch.
• docs/pages/deployment/policy.rst — operator-facing description of the service_provider block, including the RFC021-vs-RFC-7523 audience caveat.
• docs/pages/release_notes.rst — entry under Unreleased ▸ New features.

How to review

1. Start with vcr/pe/policy.go and policy/local.go — the whole functional change is ~10 lines.
2. Look at policy/local_test.go — every new test fixture is referenced from a subtest in TestStore_LoadFromFile. Note the malformed fixture (policy/test/invalid/invalid_service_provider_pd.json) deliberately omits a valid organization so the schema error can only originate from the service_provider field.
3. Verify the operator-doc paragraph in docs/pages/deployment/policy.rst is accurate for the protocol semantics — the verifier silently ignores WalletOwnerServiceProvider keys today, which is correct for RFC021 but worth confirming you agree that documenting it (rather than guarding against it) is the right call.
4. The four other modified consumers of WalletOwnerMapping (under auth/) are intentionally untouched in this PR; PR Two-VP token request flow (4078-2) #4227 wires the client-side flow.

Deviations from spec

• Naming. The implementation spec called the new block client. That term overloads httpClient/authzenClient and the OAuth client_id form parameter, so the block is named service_provider instead — matching the domain term used in the PRD's prose and the snake_case convention of sibling compound keys (wallet_owner_type, scope_policy, auth.experimental.jwt_bearer_client).
• Validation relaxed. The spec says the new block is optional and existing files should still load. To make it a first-class block, the load-time check now requires "at least one of organization, service_provider, or user" instead of "organization or user". A profile that defines only service_provider is therefore valid.
• Verifier-side semantics documented, not guarded. Adding WalletOwnerServiceProvider to WalletOwnerMapping means the existing inbound-RFC021 verifier flow (PEXConsumer.next in auth/api/iam/session.go) will silently skip a service_provider entry if one ever ends up on a profile shared with that flow. This is correct behavior — RFC021 has no service-provider-PD concept — but the asymmetry is documented in the operator guide rather than enforced with a runtime guard.
• Docs and release notes updated even though the spec did not ask for it; this is a new operator-visible config block.
• Test layout. The new subtests live inside TestStore_LoadFromFile rather than a separate test function, to avoid splitting the load-success/load-failure responsibility.

Dependencies

None — this is the first PR in the #4078 chain and can be reviewed independently. PRs #4227, #4228, #4229 depend on it.

Design context

• PRD Client-side RFC 7523 JWT Bearer grant with two VPs (PSA 10.10) #4078 — overall design, including the service_provider block shape and the cross-VP field.id binding convention that PR Two-VP token request flow (4078-2) #4227 will use.
• PRD §"Policy config extension" — the snippet showing organization + service_provider + user blocks side by side is what this PR makes loadable.
• PRD §"Modules to build/modify" item 2 — "Policy config loader: support the service-provider PD block" is exactly this PR's scope.

Original implementation spec (used during AI-assisted development)

Foundational change. Adds client as a third wallet-owner type alongside organization and user in the policy config. No behavior change for existing callers. (Renamed to service_provider during implementation — see Deviations.)

What to build

• Extend the policy config loader/schema to recognize a client block per credential profile entry. Look for WalletOwnerType (or equivalent) in policy/local.go and the loader under policy/.
• The client block must be a valid PE PresentationDefinition (same shape as the existing organization and user).
• The client block is optional — entries without it must continue to load unchanged.
• No consumers wire up client in this PR — it's just loaded and made available on the in-memory policy structure.

Modules touched

• policy/local.go (and tests)
• Whatever struct holds per-profile PDs (likely a WalletOwnerMapping-shaped type) — extend or update the iteration to include client.
• Test fixture policy files: add at least one fixture that has a client block to exercise the new path.

Testing

• Unit test: a policy file with organization + client + user loads, and all three PDs are accessible.
• Unit test: a policy file with only organization (existing shape) still loads unchanged.
• Unit test: a malformed client block (e.g. invalid JSON, non-PE structure) returns a clear error.

Acceptance Criteria

• Policy loader accepts an optional service_provider PD per credential profile.
• Existing policy files (without service_provider) continue to load with no change in behavior.
• Unit tests cover present, absent, and malformed cases.
• No consumer code is changed in this PR — wiring happens in PR 2.

[qltysh]

Coverage Impact

⬆️ Merging this pull request will increase total coverage on feature/4078-jwt-bearer-two-vp by 0.01%.

Modified Files with Diff Coverage (1)

Rating	File	% Diff	Uncovered Line #s
	policy/local.go	100.0%
	Total	100.0%

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[qltysh]

1 new issue

Tool	Category	Rule	Count
qlty	Structure	Function with many returns (count = 7): loadFromFile	1