orank · Access layer · agent-readiness

Web Bot Auth directory +2 pts

This playground documents the new agent-discovery endpoint added for the orank scan: a Web Bot Auth key directory (RFC 9421 HTTP Message Signatures) published at a predictable well-known path so agents that sign their requests can be told apart from spoofers.

The endpoint

GEThttps://orchestkit.yonyon.ai/.well-known/http-message-signatures-directory

Content-Typeapplication/http-message-signatures-directory+json

Wiringrewrite in next.config.mjs → app/api/well-known/…/route.ts, allowlisted in lib/agent-404.ts (synced by agent-404.test.ts)

Response

$ curl https://orchestkit.yonyon.ai/.well-known/http-message-signatures-directory
{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "z5ufUBtSG2s-PEH_Sx2DYttadlsrQts4vAfLj2I2vUA",
      "kid": "6a120f4f14168a35",
      "use": "sig",
      "alg": "EdDSA",
      "nbf": 1782864000,
      "exp": 1814400000
    }
  ]
}

Honest scope decorative

This docs origin is anonymous read-only and does not currently operate a request-signing bot, so the published key is a valid but unused verification key — an agent-awareness signal, not a load-bearing credential. The matching private key is held out-of-band and never committed. It earns the orank Access point without fabricating an auth flow that doesn't exist (unlike filling in fake authorization_servers, which we deliberately do not do).

Where it sits in the orank picture

on-siteThis is the last honest on-site Access fix. NLWeb /ask+SSE, docs-MCP multi-surface, robots Content-Signals, llms.txt, RFC 9728 PRM are already live.

off-siteThe real ceiling is Discovery (5/21), capped by the yonyon brand collision — tracked as marketing issues in yonatan-hq/platform (Wikipedia · brand-SEO · citation corpus · citation quality).

Verified via vitest (pure handler invocation, no network): __tests__/web-bot-auth.test.ts + the agent-404 rewrite↔allowlist sync guard. Spec: RFC 9421 HTTP Message Signatures · orank methodology.