Summary
www.datum.net's /auth.md correctly points agents at OAuth discovery, and /.well-known/oauth-protected-resource on www.datum.net correctly names https://auth.datum.net as the authorization server (per RFC 9728). But per RFC 8414, Authorization Server Metadata has to be served by the issuer itself — https://auth.datum.net/.well-known/oauth-authorization-server — not by the resource server (www.datum.net). That path 404s on auth.datum.net today.
An isitagentready.com scan follows exactly this chain and fails on it:
GET https://www.datum.net/.well-known/oauth-protected-resource → 200, names auth.datum.net as AS
GET https://auth.datum.net/.well-known/oauth-authorization-server → 404
Result: checks.discovery.authMd: "auth.md exists but agent_auth metadata was not found".
Context
datum-cloud/datum.net already publishes a /.well-known/oauth-authorization-server — but on its own domain (www.datum.net), which isn't the origin RFC 8414-following clients will check. That file mirrors auth.datum.net's real published openid-configuration fields and adds an agent_auth extension block (see PR #1716) — reusable content, wrong host.
Ask
Serve the equivalent file from auth.datum.net itself:
https://auth.datum.net/.well-known/oauth-authorization-server
Content can be copied directly from datum-cloud/datum.net's public/.well-known/oauth-authorization-server (same repo also has the exact real values for every endpoint, since they were sourced from auth.datum.net's own openid-configuration).
Where this belongs
Not sure whether that's this repo (if it fronts auth.datum.net's routing) or Zitadel's own config, or an edge/proxy layer in front of it — auth.datum.net's /.well-known/openid-configuration already 200s, so whatever serves that can likely serve this too. Filing here first since it's Datum's custom auth surface; reassign if the actual well-known routing lives elsewhere.
References
Summary
www.datum.net's/auth.mdcorrectly points agents at OAuth discovery, and/.well-known/oauth-protected-resourceonwww.datum.netcorrectly nameshttps://auth.datum.netas the authorization server (per RFC 9728). But per RFC 8414, Authorization Server Metadata has to be served by the issuer itself —https://auth.datum.net/.well-known/oauth-authorization-server— not by the resource server (www.datum.net). That path 404s onauth.datum.nettoday.An isitagentready.com scan follows exactly this chain and fails on it:
Result:
checks.discovery.authMd: "auth.md exists but agent_auth metadata was not found".Context
datum-cloud/datum.netalready publishes a/.well-known/oauth-authorization-server— but on its own domain (www.datum.net), which isn't the origin RFC 8414-following clients will check. That file mirrorsauth.datum.net's real publishedopenid-configurationfields and adds anagent_authextension block (see PR #1716) — reusable content, wrong host.Ask
Serve the equivalent file from
auth.datum.netitself:Content can be copied directly from
datum-cloud/datum.net'spublic/.well-known/oauth-authorization-server(same repo also has the exact real values for every endpoint, since they were sourced fromauth.datum.net's ownopenid-configuration).Where this belongs
Not sure whether that's this repo (if it fronts
auth.datum.net's routing) or Zitadel's own config, or an edge/proxy layer in front of it — auth.datum.net's/.well-known/openid-configurationalready 200s, so whatever serves that can likely serve this too. Filing here first since it's Datum's custom auth surface; reassign if the actual well-known routing lives elsewhere.References