Identity Deep Dive

Client ID Metadata Documents

The client_id is an HTTPS URL that serves the client's metadata, so clients need no registration step at each server.

Where it stands
Working-group draft
Official text
draft-ietf-oauth-client-id-metadata-document-03
2026-11-02
Documented support
3
Activity
1 signals in 90 days

No explainer written for this spec yet. The summary, relations and documented support below are maintained.

The client_id is an HTTPS URL that serves the client's metadata, so clients need no registration step at each server.

How it relates to other specs

Relations diagram
flowchart LR
  s_cimd["Client ID Metadata Documents"]
  s_dcr["Dynamic Client Registration"]
  style s_cimd stroke-width:3px
  s_cimd -.-|Alternative to| s_dcr

Documented support

Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.

Products, identity providers and services

  • Model Context Protocol (Specification): MCP authorization spec has clients use Client ID Metadata Documents when the authorization server indicates support source (verified 2026-11-11)
  • Ping Identity (PingFederate 13.1) (Identity provider): PingFederate 13.1 supports Client ID Metadata Documents for OAuth clients source (verified 2026-11-11)
  • Keycloak (Identity provider)experimental: Keycloak's MCP integration guide lists CIMD support as experimental source (verified 2026-11-11)

Activity

Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.

Explanations on this site

  • DiscussionOAuth WG

    Weekly digest: big issue cleanup on the client-id-metadata-document draft, two new ID-JAG issues, and several sd-jwt-vc PRs.

    Weekly github digest (OAuth Activity Summary)

    Read the explanation

    The digest lists GitHub activity only, with no spec text. In draft-ietf-oauth-client-id-metadata-document, 11 issues were closed, including those on token_endpoint_auth_method with private_key_jwt (#100), guidance on omitting token_endpoint_auth_method (#92), unsupported metadata values (#71), AS error returns (#85), disallowing the root path as a URL (#86) and data URIs for logo_uri (#19). One new issue (#131) says the response_types intersection rejects otherwise usable token-endpoint grants. Three PRs were opened, and PR #99 (Add Client Authentication section) got a comment. For oauth-identity-assertion-authz-grant, mcguinness opened #160 (sender-constrained ID-JAG should not replace required client authentication) and #159 (sections 7.2 and 8 require jwt-bearer but omit jwt-dpop). oauth-sd-jwt-vc got 7 new PRs, and PR #450 (Mike Bishop's ballot) got a comment. oauth-v2-1 PR #268 (supporting OAuth 2.0 and 2.1 clients concurrently) got 3 comments. oauth-transaction-tokens got 1 new PR. The digest does not show the reasons for the closures or the content of the PRs.

    • An authorization server implementing client ID metadata documents wants to know whether the client authentication and response_types handling rules are still changing.
    • An implementer of the ID-JAG grant who plans to use DPoP should watch #159 and #160 on the jwt-dpop gap and on client authentication.

On the mailing list