Summary
Add test-servers/configs/oauth-cimd-http.json and teach the composable test server to host a CIMD client metadata document, so URL-based client IDs (SEP-991) can be exercised against a local server.
Why
In CIMD the client_id is a URL that the authorization server dereferences to learn the client's metadata. Nothing in this repo served such a document, so a fixture could advertise client_id_metadata_document_supported and still be unusable — exercising CIMD meant standing up a second host by hand.
That is why #2242 shipped verified by its tests alone. The v2.6.0 release smoke recorded it as the one contribution with an observable UI surface (Connection Info reporting the registration kind) that could not be reached, and named this fixture as the missing piece.
Scope
oauth.clientMetadata / oauth.clientMetadataPath config, and a route serving the document when supportCIMD is on. The document's client_id is derived from the request, not from a configured issuer, so it stays correct when the harness picks the port.
oauth-cimd-http.json, with supportDCR: false — see below.
- An integration test covering the fixture's own invariants.
docs/test-servers.md section.
supportDCR: false is the load-bearing choice
With DCR available, a CIMD failure silently succeeds via dynamic registration and the reproduction proves nothing. This is not hypothetical: while building this, a misconfigured run connected happily and reported Dynamic (DCR) with a test_client_… id, which looks like success until you read the client id. With DCR off, CIMD is the only path that can complete, so reaching a connected state is itself the assertion.
The integration test pins this (expect(metadata.registration_endpoint).toBeUndefined()) precisely so nobody "helpfully" turns DCR on later.
What this does not fix
The Inspector requires the CIMD metadata URL to be HTTPS with no loopback exemption, so this server's own http:// document is not a usable clientMetadataUrl. Driving the UI end to end still needs a self-signed HTTPS listener plus NODE_TLS_REJECT_UNAUTHORIZED=0 for the test server's own fetch. That asymmetry is #2305; this issue delivers the fixture, and #2305 is what makes it pleasant to use.
Verified with that workaround during the v2.6.0 smoke: Connection Info read Client registration — Client ID Metadata (CIMD) with the client id equal to the metadata URL, against a server advertising no registration endpoint.
Acceptance
Summary
Add
test-servers/configs/oauth-cimd-http.jsonand teach the composable test server to host a CIMD client metadata document, so URL-based client IDs (SEP-991) can be exercised against a local server.Why
In CIMD the
client_idis a URL that the authorization server dereferences to learn the client's metadata. Nothing in this repo served such a document, so a fixture could advertiseclient_id_metadata_document_supportedand still be unusable — exercising CIMD meant standing up a second host by hand.That is why #2242 shipped verified by its tests alone. The v2.6.0 release smoke recorded it as the one contribution with an observable UI surface (Connection Info reporting the registration kind) that could not be reached, and named this fixture as the missing piece.
Scope
oauth.clientMetadata/oauth.clientMetadataPathconfig, and a route serving the document whensupportCIMDis on. The document'sclient_idis derived from the request, not from a configured issuer, so it stays correct when the harness picks the port.oauth-cimd-http.json, withsupportDCR: false— see below.docs/test-servers.mdsection.supportDCR: falseis the load-bearing choiceWith DCR available, a CIMD failure silently succeeds via dynamic registration and the reproduction proves nothing. This is not hypothetical: while building this, a misconfigured run connected happily and reported
Dynamic (DCR)with atest_client_…id, which looks like success until you read the client id. With DCR off, CIMD is the only path that can complete, so reaching a connected state is itself the assertion.The integration test pins this (
expect(metadata.registration_endpoint).toBeUndefined()) precisely so nobody "helpfully" turns DCR on later.What this does not fix
The Inspector requires the CIMD metadata URL to be HTTPS with no loopback exemption, so this server's own
http://document is not a usableclientMetadataUrl. Driving the UI end to end still needs a self-signed HTTPS listener plusNODE_TLS_REJECT_UNAUTHORIZED=0for the test server's own fetch. That asymmetry is #2305; this issue delivers the fixture, and #2305 is what makes it pleasant to use.Verified with that workaround during the v2.6.0 smoke: Connection Info read
Client registration — Client ID Metadata (CIMD)with the client id equal to the metadata URL, against a server advertising no registration endpoint.Acceptance
oauth-cimd-http.jsonboots and serves/client-metadata.jsonclient_idequals the URL it was fetched fromsupportCIMDis falseregistration_endpointdocs/test-servers.mddocuments the fixture, the install-levelclient.jsonlocation, and the HTTPS constraintnpm run local:gatepasses