Repository navigation
Roadmap: operational, manually testable AS / DC / TP — prioritized open issues #255
Description
Purpose
Prioritise every open issue towards one objective: operational Authorization Server, Data Custodian and Third Party applications that can be tested by hand, quickly. Phases run in order. Within a phase, the order is the critical path. Size: S ≈ a day, M ≈ a few days, L ≈ a week or more.
Principles: unblock the end-to-end flow before adding breadth; make local setup reproducible before debugging it; fix wrong data exposure before anything is shared; one source of truth for each concern (schema = Flyway, access rules = one policy, registration = RFC 7591).
Phase 1: Manually testable locally (critical path)
Exit criteria: scripts/local/start-all → smoke passes; a TP user logs in to the TP, authorizes access, logs in and consents at the DC, the TP receives a token, and the TP displays that customer's usage data. Admin and token checks run from docs/LOCAL_TESTING.md.
| # | Item | Size | Why now |
|---|---|---|---|
| 1 | #254 Local manual-test kit (aligned local profiles, AS admin bootstrap, start/stop/smoke scripts, runbook) | S | Removes the hidden-secret and mismatch friction; everything after builds on it |
| 2 | #253 DC local sample dataset (with the DC-local slice of #241: Flyway on H2) | S–M | Without data, consent and feeds can't be exercised |
| 3 | #232 AS → DC delegation drops the authorize parameters (400) | S | Blocks the customer flow |
| 4 | #249 TP username/password login | M | A TP user must exist to start the flow; today the login button gives a 500 |
| 5 | #146 TP OAuth client wiring (authorize → callback → token storage) + #202 token-response URIs | M | TP must obtain and store the token and know where the customer's resources are |
| 6 | #197 (rest: <atom:content>, getResource(), empty feed) + minimal #89 (fetch and display a UsagePoint and its readings) |
M | TP must show data to prove the flow end to end |
| 7 | #211 customer scope narrowing → invalid_scope |
S–M | Consent with fewer function blocks must work |
| 8 | #225 401 (not 302) on unauthenticated token / introspect / revoke; #234 missing AS H2 tables | S + S | Makes curl testing and the logs trustworthy |
Phase 2: Safe to share (sandbox / demo deployment)
| # | Item | Size | Notes |
|---|---|---|---|
| 9 | Fixes for privately reported security advisories (tracked in GitHub Security Advisories) | M | Before anything is exposed beyond localhost |
| 10 | #187 resource scoping: ESPI GETs must be limited to the token's Subscription/Authorization (today Subscription-scoped GETs ignore subscriptionId, per CLAUDE.md) |
L | Prevents one customer's data being returned for another's token |
| 11 | #138 consent withdrawal → token revocation + subscription cleanup | M | |
| 12 | #251 registration access token (RFC 7591 + FB=36_40 renewal, DC accepts it for ApplicationInformation) → #252 TP self-registration |
M + L | Replaces the seeded TP client; spike done |
| 13 | #131 dependency CVEs; #237 CodeQL triage | M | |
| 14 | #241 (rest) + #145 / #123 / #152 vendor schema alignment; #200 audit-log writers; #199 abandoned-authorization cleanup | M–L | Needed for the MySQL/PostgreSQL deployment profiles |
| 15 | #233 metadata advertises unsupported JWT/JWKS features; #188 TLS certificates | S + M |
Phase 3: ESPI completeness and certification readiness
#119 epic, #187 (E1 engine: all resources), full #89 import, #168 / #169 / #101 schema compliance, #245 DC customer portal (usage, Download My Data), #186 AS home page.
Continuous: quality and hygiene (pick up alongside)
#151 rebuild the AS OAuth flow integration suite (it would have caught #232; prioritise it early in Phase 2), #194 skipped/disabled tests, #78 timestamp-resolution flake (seen again: CustomerAccountRepositoryTest.shouldUpdateTimestampsOnModification), #88, #103, #133.
Recommended to close (reviewer: please confirm)
| # | Reason |
|---|---|
| #141 | Done in #250: DC Authorization endpoints implemented with per-TP filtering (AdminCaller, AdminRowScopeTest) |
| #204 | Done: admin API bearer tokens are on main (merged with the GHSA-mh65 fix, 40812eb) |
| #205 | Done: admin user store + passkey MFA + bootstrap are on main (same merge) |
| #203 | Superseded by #251: the certification question is answered, since REQ.21 requires the registration access token |
| #98 | Delivered by #116; no description of its own; remaining work is in #187 / #119 |
| #117 | Obsolete: pr-checks.yml no longer exists, and no workflow runs Spotless |
Decisions needed
- Third Party: register itself via RFC 7591 dynamic client registration and manage its registration #252: how a Third Party receives its RFC 7591 initial access token during onboarding (DC operator, GBA, or another out-of-band step).
- Registration access token: issue it on RFC 7591 registration, renew via FB=36_40, and require it for ApplicationInformation #251: RFC 7592 (Experimental) says a registration access token should not expire while the client is registered; ESPI renews an expired one through
FB=36_40. Document this as a deliberate ESPI profile choice. - Third Party cannot unmarshal any ESPI Atom feed (AtomFeedDto date adapters + abstract entry type) #197: adopting the
<atom:content>wrapper changes the wire format for both DC export and TP import. Confirm it should be done as one change.
References
RFC 7591 (Dynamic Client Registration), RFC 7592 (Registration Management, Experimental), NAESB REQ.21 v4.1, CLAUDE.md "Known Issues"
🤖 Generated with Claude Code
Activity
dfcoffin commentedon Nov 14, 2026
Roadmap update:
Batch/BulkAPI, Third Party client access token only) next to ESPI token-response URIs: FB_51 gating, re-provisioning on refresh, missing URIs for client_credentials tokens #202. Registration access token: issue it on RFC 7591 registration, renew via FB=36_40, and require it for ApplicationInformation #251 now also covers grantingclient_credentialsto registered Third Parties, limited by the server toThirdParty_Admin_AccessandFB=36_40, so customer FB scopes can only come fromauthorization_code.🤖 Generated with Claude Code