Allow client_credentials for CIMD clients — unattended agents have no browser

[rsharath]

Context

Prep for the OpenID AIIM CG MCP Security Interoperability Event (Gartner IAM Summit, Dec 7–9 2026).

Filed separately from #264 because the product gap is bigger than the matrix row.

The gap

CIMD clients may only use authorization_code and refresh_token:

// internal/service/cimd.go:146 — cimdAllowedGrantTypes
// "CIMD is the interactive-onboarding path, so authorization_code (and its refresh
//  companion) are the only sensible grants — client_credentials / token-exchange
//  clients register through the admin or RFC 7591 path instead."

That reasoning holds for a desktop client with a user at a browser. It does not hold for the case the interop event exists to address.

Why it matters beyond the matrix

The interop plan's own framing (p.3): EDR/UEM can gate agents on managed desktops, but "enabling authorized clients to run in the cloud requires other strategies" — and CIMD is presented as that strategy.

An unattended cloud agent has no browser and no interactive user. authorization_code is unavailable to it by construction. With client_credentials off the table for CIMD clients, such an agent has exactly two options against ZeroID:

1. pre-register through the admin path — which is the registration CIMD exists to remove, and does not scale to an open agent ecosystem; or
2. carry a long-lived client secret — the anti-pattern the whole event is meant to retire.

So the grant-type allow-list quietly excludes the deployment shape that motivates the feature.

The plan hedges here too (p.3, "Some OAuth servers may also support Client Credential Grants to issue tokens in a 2-step flow"), which is worth pushing back on with the CG — for agents the unattended case is not a footnote.

Scope

Permit client_credentials for CIMD clients, authenticated by private_key_jwt against the document's published key set.

Depends on #264 (and transitively #206). Sequencing matters: client_credentials with no client authentication would let anyone who can read a CIMD URL mint tokens as that client. The key-based auth is the whole control, so this must not land first.

Acceptance

Flip tests/api/mcp_interop/test_cimd_matrix.py::test_row_client_credentials[jwt] from xfail(strict=True).

The [client_secret] and [mtls] parametrisations stay xfail — a secret defeats the point of CIMD, and tls_client_auth is deferred per #206.