Preflight Checklist
Describe your problem
The OAuth Client ID Metadata Document draft (draft-ietf-oauth-client-id-metadata-document, OAuth WG) lets a client use an HTTPS URL as its client_id, where the URL resolves to a client metadata document. An Authorization Server that supports this advertises it through a standard Authorization Server Metadata field, client_id_metadata_document_supported (boolean, Section 5 of the draft).
DiscoveryConfiguration in pkg/oidc/discovery.go has no field for this today, so a provider built on this library cannot announce the capability in its /.well-known/openid-configuration.
Motivation: this is the discovery building block for adding MCP authorization to providers built on zitadel/oidc. MCP's client identification work (modelcontextprotocol SEP-991) relies on CIMD so MCP clients can be identified by URL without prior registration.
Describe your ideal solution
Add a single additive boolean field to DiscoveryConfiguration:
// ClientIDMetadataDocumentSupported indicates whether the OP can resolve a client_id that is an
// HTTPS URL pointing to a client metadata document, per the OAuth Client ID Metadata Document spec.
ClientIDMetadataDocumentSupported bool `json:"client_id_metadata_document_supported,omitempty"`
plus a JSON (de)serialization test.
Scope is intentionally minimal:
- No change to the
op.Server interface.
- No handler and no CIMD resolution logic (that lives in the AS implementation).
omitempty, so existing providers see no change in their discovery output.
Wiring an op option to set the flag from configuration can be a follow-up, following the pattern discussed for registration_endpoint in #763 / #782.
Additional context
Happy to raise the PR (additive, no interface change).
Preflight Checklist
Describe your problem
The OAuth Client ID Metadata Document draft (draft-ietf-oauth-client-id-metadata-document, OAuth WG) lets a client use an HTTPS URL as its
client_id, where the URL resolves to a client metadata document. An Authorization Server that supports this advertises it through a standard Authorization Server Metadata field,client_id_metadata_document_supported(boolean, Section 5 of the draft).DiscoveryConfigurationinpkg/oidc/discovery.gohas no field for this today, so a provider built on this library cannot announce the capability in its/.well-known/openid-configuration.Motivation: this is the discovery building block for adding MCP authorization to providers built on zitadel/oidc. MCP's client identification work (modelcontextprotocol SEP-991) relies on CIMD so MCP clients can be identified by URL without prior registration.
Describe your ideal solution
Add a single additive boolean field to
DiscoveryConfiguration:plus a JSON (de)serialization test.
Scope is intentionally minimal:
op.Serverinterface.omitempty, so existing providers see no change in their discovery output.Wiring an
opoption to set the flag from configuration can be a follow-up, following the pattern discussed forregistration_endpointin #763 / #782.Additional context
client_id_metadata_document_supported. https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/registration_endpointmetadata via option. #763 and Feature/support dynamic registration management rfc7591 rfc7592 #1 #782 (registration_endpoint / dynamic client registration). This change is complementary and does not overlap with Feature/support dynamic registration management rfc7591 rfc7592 #1 #782.Happy to raise the PR (additive, no interface change).