feat(agents): fix ARD manifest, publish auth.md and OAuth AS metadata

[felixwidjaja]

Addresses two of the three isitagentready.com findings passed along; DNS-AID (the third) is tracked separately as blocked (#1715).

ARD manifest — entry 0 is missing displayName

/.well-known/ai-catalog.json was missing displayName on its one entry, and had no top-level host object or representativeQueries — all required by the ARD spec. Content-Type was also application/ai-catalog+json instead of the spec's plain application/json.

Fixed the existing MCP entry and added a second, real entry for this site's own /openapi.json.

auth.md — not found

Didn't exist. Added /auth.md, referencing the existing /.well-known/oauth-protected-resource metadata rather than duplicating it, per the spec's "when OAuth metadata is available, reference it" guidance.

OAuth Authorization Server metadata

astro.config.mjs/server.mjs already had a content-type mapping registered for /.well-known/oauth-authorization-server — but no file ever backed it, so it 404'd. Added one (RFC 8414 shape, mirroring the real fields already published in openid-configuration), plus:

• agent_auth extension block on it, per the auth.md spec
• bearer_methods_supported: ["header"] on oauth-protected-resource (spec requires it)
• Link headers for both new endpoints (+ ai-catalog.json, auth.md) in server.mjs

A judgment call worth flagging: agent_auth's identity flow

The auth.md skill's spec names three identity flows for the agent_auth block — ID-JAG, verified-email, anonymous — each with specific required sub-fields. None of them match how Datum's IAM actually works today: real OAuth service accounts via client_credentials / urn:ietf:params:oauth:grant-type:jwt-bearer (confirmed live in openid-configuration's grant_types_supported), not token-exchange federation, not an email-linked agent identity, and definitely not anonymous access.

Rather than force-fit the data into one of those three shapes to make the scanner's flow-check happy, agent_auth here describes the real mechanism under identity_types_supported: ["service_account"], with real endpoints — register_uri is the actual signup URL (https://auth.datum.net/id/signup), revocation_uri is the real revocation_endpoint. This may not get a full green check on that specific sub-check, but it doesn't misrepresent what Datum's auth does — same "don't overclaim" principle already established in src/data/openapi.ts and src/data/mcpServerCard.ts.

Test plan

• npx astro check — 0 errors
• npm run build — succeeds; oauth-authorization-server copies to dist/client/.well-known/ correctly
• Both edited JSON files parse (python3 -m json.tool)
• POST https://isitagentready.com/api/scan {"url": "https://www.datum.net"} post-deploy — confirm checks.discovery.ard.status and checks.discoverability.authMd.status

🤖 Generated with Claude Code

[github-actions]

🔎 SEO & Meta Review

Skipped (mode: skipped-no-pages).

Changed files do not include any src/pages or src/content entries.