Integration test: jwt-bearer two-VP token request payload (4078-4)

[stevenvegt]

Parent PRD

#4078

Summary

End-to-end integration test that boots a real Nuts node, drives the
request-service-access-token API with service_provider_subject_id, and
asserts the resulting token-request form body matches the PSA 10.10.6 /
RFC 7523 jwt-bearer wire format. Both captured VPs are round-tripped through
the same node's /internal/vcr/v2/verifier/vp endpoint to confirm signatures
verify and the cross-VP delegation binding holds end-to-end with real keys.

This is the last PR in the #4078 stack. It validates that #4226 (policy
config), #4227 (two-VP flow), and #4228 (API binding) compose correctly under
real cryptographic signing and real DID resolution, coverage the mock-based
unit tests cannot provide.

What changed

• Adds auth/api/iam/jwtbearer_integration_test.go, a single happy-path test
  that:
  • Boots a Nuts node with NUTS_AUTH_EXPERIMENTAL_JWTBEARERCLIENT=true and a
    medication-overview policy with shared delegating_hcp field-id binding
    across organization and service_provider PDs.
  • Provisions four did:web subjects (CIBG issuer, Twiin issuer, HCP org,
    service provider) and issues the three credentials required by the
    profile (HealthcareProviderCredential, ServiceProviderCredential,
    ServiceProviderDelegationCredential).
  • Stands up an httptest.Server mock AS that advertises jwt-bearer support
    and synchronously captures the form POST to /token.
  • Asserts wire-format invariants on the captured form (grant_type,
    client_assertion_type, scope, presence of both assertion and
    client_assertion, absence of presentation_submission).
  • Round-trips both captured VPs through the node's verifyVP endpoint and
    asserts the cross-VP binding (delegation credential issuer == VP1 signer,
    delegation delegatedBy URA == HCP credential URA).

How to review

• Start with TestIntegration_JwtBearer_TwoVPHappyPath to see the overall
  flow.
• The wire-format assertions live in the main test function; the
  verifyVP round-trips and cross-VP binding checks follow.
• Helpers below (mockAS, provisionSubject, issueAndLoad, credential
  builders, pluckCredentialByType, firstSubject, firstIdentifierValue)
  are scoped to this file and exist purely to keep the test readable.
• mockAS.capturedForm(t) is synchronous: the IAMClient's /token POST
  completes inside the API call, so the captured form is set by the time
  the API returns 200. No polling; failures (parse error or never-called)
  surface as test failures, not silent empty maps.
• The format-key conventions used here differ across three specs (issuer API
  uses jwt_vc, PE policy uses jwt_vc/jwt_vp, AS metadata uses
  jwt_vc_json/jwt_vp_json). The header comment on issueAndLoad spells
  this out.

Deviations from spec

The implementation spec calls for negative-path assertions in this
integration test (AS doesn't advertise jwt-bearer, missing service_provider
PD, feature flag disabled). Those scenarios are instead covered by the
mock-based tests added in #4227 and #4228:

• Feature-flag-off, missing service_provider PD, AS doesn't advertise
  jwt-bearer: auth/client/iam/openid4vp_test.go.
• service_provider_subject_id validation at the API layer:
  auth/api/iam/api_test.go.

This integration test focuses exclusively on the happy-path round trip,
where the value is real crypto + real DID resolution + real verifyVP,
things unit tests cannot exercise. The file header comment in
jwtbearer_integration_test.go documents this scope decision.

Dependencies

This is PR #4 of 4 in the #4078 stack. It targets 4078-3-api-client-id so
the diff shows only the integration test. Review order:

1. Policy config: add client PD block (4078-1) #4226: policy config (service_provider PD block)
2. Two-VP token request flow (4078-2) #4227: two-VP flow
3. API binding: accept service_provider_subject_id on request-service-access-token (4078-3) #4228: API binding (service_provider_subject_id)
4. Integration test: jwt-bearer two-VP token request payload (4078-4) #4229: this PR

All three predecessors are approved and out of draft as of opening.

Design context

• PRD Client-side RFC 7523 JWT Bearer grant with two VPs (PSA 10.10) #4078, "Client-side RFC 7523 JWT Bearer grant with two VPs (PSA 10.10)".
• The cross-VP binding mechanism (shared field.id on
  $.issuer) is described in the PRD's "Cross-VP field binding" section. This
  test exercises it end-to-end: the captured VP2's
  ServiceProviderDelegationCredential.issuer must equal the DID that signed
  VP1.
• PSA 10.10.6 wire format expectations are pinned in the PRD's "Token request
  parameters (jwt-bearer flow)" section.

Original implementation spec (used during AI-assisted development)

Parent PRD

#4078

Implementation Spec

Integration safety net. Asserts the full client-side flow produces a PSA 10.10.6-conformant token request and that both VPs verify cleanly through the existing VCR verifyVP API.

What to build

In-process Go integration test (under auth/api/iam/, extend or add alongside the existing integration_test.go). No docker-compose; that's reserved for cross-node workflows.

Test setup

1. Spin up a single Nuts node test instance with the experimental feature flag enabled.
2. Pre-provision two subjects in its wallet:
   • HCP subject with credentials matching the organization PD (e.g. HealthcareProviderCredential).
   • SP subject with a ServiceProviderDelegationCredential whose issuer is one of the HCP subject's DIDs.
3. Configure the policy with a medication-overview profile that has both organization and client PDs, sharing a delegating_hcp field id on $.issuer.
4. Stand up an httptest.Server mock AS that:
   • Serves oauth-authorization-server metadata advertising urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported.
   • Captures the form POST body received on the token endpoint.
   • Returns a canned valid token response so the client doesn't error.

Positive path assertions

• Call POST /internal/auth/v2/{HCP-subjectID}/request-service-access-token with body containing client_id, authorization_server (mock AS URL), and a mixed scope.
• Inspect the captured form POST body:
  • grant_type equals urn:ietf:params:oauth:grant-type:jwt-bearer.
  • client_assertion_type equals urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
  • scope matches what was requested.
  • assertion and client_assertion are both present and non-empty.
  • No presentation_submission form parameter is present.
• Submit the captured assertion JWT-VP to the same node's POST /internal/vcr/v2/verifier/vp and assert validity: true. Inspect the verified credentials, VP1 must contain the expected HCP credentials and be signed by the HCP DID.
• Submit the captured client_assertion JWT-VP the same way. VP2 must contain the delegation credential, be signed by the SP DID, and the delegation's issuer must equal the HCP DID that signed VP1 (cross-VP binding verified end-to-end).

Negative path assertions

• Same setup but mock AS metadata omits jwt-bearer from grant_types_supported: API call returns 400 with a clear error.
• Same setup but no client PD configured for the requested profile: API call returns 400.
• Feature flag disabled + client_id present: API call returns 400 (feature disabled).

Modules touched

• auth/api/iam/integration_test.go (or a new sibling test file for the jwt-bearer flow).
• Possibly test fixture policies and credentials under test/ or alongside.

Why no docker e2e

PSA 10.10.6 server-side support is out of scope for #4078 (separate PRD). There is no second Nuts node that can receive and validate the request. A mock AS via httptest is the appropriate level, the test verifies wire format and round-trips both VPs through the same node's verifyVP for proof validation.

Acceptance Criteria

• Integration test exists and runs as part of the standard test suite (no docker, no extra setup).
• Positive path: form body matches PSA 10.10.6 wire format; both VPs verify via verifyVP; cross-VP binding holds end-to-end.
• Negative paths covered: AS unsupported, no client PD, feature flag disabled. (Covered in unit tests in Two-VP token request flow (4078-2) #4227/API binding: accept service_provider_subject_id on request-service-access-token (4078-3) #4228 rather than this integration test, see "Deviations from spec".)
• Test runs reliably (no flakes, no external network dependencies).

[qltysh]

Coverage Impact

⬆️ Merging this pull request will increase total coverage on 4078-3-api-client-id by 0.13%.

🚦 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.

[reinkrul]

pluck?