eSignet-Thunder: Bug — Nine smaller conformance and consistency gaps found across client-mgmt, PAR, token and userinfo #2539

Short Summary of the Bug

Nine small defects found while running the Go beta API matrix. None is individually severe; they are grouped here as one tracking issue because each is a one-line fix in a different place. Each item below is independently reproducible.

Steps to Reproduce

Environment for all items: eSignet Go (Thunder beta) — provider https://esignet-go.esqa.mosip.net, Mock Identity, UIN 22222222222 / OTP 111111.

1. Duplicate userClaims accepted — POST /client-mgmt/client with "userClaims": ["name","name"].
2. request_uri lifetime is 3600 s — POST /oauth2/par and read expires_in.
3. redirect_uri optional at PAR — POST /oauth2/par omitting redirect_uri entirely.
4. relyingPartyId not checked — register a client with "relyingPartyId": "no-such-rp".
5. GET /client-mgmt/client/{id} returns almost nothing — register a client, then read it back.
6. birthdate format — complete a login and read birthdate from GET /oauth2/userinfo.
7. Inconsistent code invalidation — obtain a code, fail the exchange once with a wrong code_verifier, retry with the correct one; separately, fail an exchange with a bad DPoP proof and retry cleanly.
8. Empty KBI inputs reach the executor — on the KBI node submit blank username, fullName, dob.
9. captcha_token value not verified — on the OTP login-ID node submit captcha_token: "wrong-value-123".

Actual Result

1. 200 ACTIVE — accepted. Every other list field (redirect URIs, ACRs, grant types, auth methods, scopes) is de-duplicated; validateClaims has no uniqueness check.
2. expires_in: 3600.
3. 201 — accepted with no redirect_uri at all.
4. 200 ACTIVE — no referential check against known relying parties.
5. 200 but the body carries only clientId and status; redirect URIs, claims, ACRs and additionalConfig cannot be read back.
6. "birthdate": "1987/11/25".
7. The PKCE failure burns the authorization code (retry → invalid_grant), but a DPoP-proof failure leaves it usable (retry → 200 with a token).
8. FET-1005 invalid_credentials rather than a required-field prompt — unlike the OTP node, which correctly re-prompts for a missing captcha_token.
9. The flow advances to the OTP node — the token's presence is required but its value is not validated.

Expected Result

1. Reject duplicates with invalid_claim, consistent with every other list field.
2. RFC 9126 §2.2 expects a short-lived request_uri; FAPI 2.0 deployments typically use 60–90 s.
3. FAPI 2.0 §5.3.1 requires the client to send redirect_uri and the AS to require it.
4. relyingPartyId is validated against existing relying parties / OUs.
5. The read endpoint returns the stored configuration so a caller can verify an update.
6. OIDC Core requires YYYY-MM-DD — 1987-11-25.
7. Code invalidation on a failed exchange is consistent across failure types.
8. Blank required inputs are caught as field validation, matching the OTP node's behaviour.
9. captcha_token is validated against the configured captcha service (MOSIP_ESIGNET_CAPTCHA_VALIDATOR_URL). Note: item 9 may be intentional configuration for this environment — please confirm the intended posture rather than treating it as a code defect.

Screenshot/Screen Recording

Not applicable — API-level items; the transcripts above are the evidence.

Attachments / Evidence / Links

• Related test cases in the Go beta verification sheet: GO-API-0695 (item 1), GO-API-0671/0672 (item 2), GO-API-0700 (item 3), GO-API-0679/0680 (item 5), GO-API-0677/0678 (item 7), GO-API-0687 (item 8), GO-API-0688 (item 9).
• Verified on Mock Identity. Items 1–7 are in client-mgmt, PAR, token and userinfo, which do not depend on the identity plugin, so they apply to the MOSIP Identity and Sunbird Identity deployments as well. Item 8 concerns the Sunbird KBI executor specifically and was exercised only through its zero-match path on this deployment. Item 9 depends on the captcha configuration of each environment. Only the Mock instance was exercised for this report.