{
 "acronym": "",
 "adoption": {
  "by": null,
  "level": "unmeasured",
  "probe_run": null
 },
 "aliases": [
  "RFC 9728",
  "RFC 8414",
  "PRM",
  "AS Metadata"
 ],
 "analog": "A site's published API documentation entry point, made machine-readable",
 "collisions": [],
 "discovery": {
  "mechanism": "well-known files at the resource server and the authorization server, chained by a WWW-Authenticate challenge",
  "path": "/.well-known/oauth-protected-resource"
 },
 "dispute": null,
 "evidence": [
  {
   "claim": "RFC 9728, 'OAuth 2.0 Protected Resource Metadata,' is an Internet Standards Track document representing IETF consensus, defining a metadata format an OAuth 2.0 client or authorization server uses to learn how to interact with a protected resource.",
   "date": "2025",
   "label": "VERIFIED",
   "url": "https://www.rfc-editor.org/rfc/rfc9728.html"
  },
  {
   "claim": "RFC 8414, 'OAuth 2.0 Authorization Server Metadata,' published June 2018, is an Internet Standards Track document defining the companion metadata format for an authorization server's own endpoints and capabilities.",
   "date": "2018-06",
   "label": "VERIFIED",
   "url": "https://www.rfc-editor.org/rfc/rfc8414.html"
  },
  {
   "claim": "The auth.md specification (a distinct, single-vendor agent-registration protocol) documents both RFCs being chained together in a live agent-discovery flow: a 401's WWW-Authenticate header points to RFC 9728 Protected Resource Metadata, which points to RFC 8414 Authorization Server Metadata.",
   "date": "2026-06",
   "label": "REPORTED",
   "url": "https://auth-md.com/specification"
  }
 ],
 "form": "well-known-file",
 "governance": "IETF OAuth Working Group; both are Internet Standards Track RFCs with IETF/IESG consensus",
 "group": null,
 "history": [
  {
   "date": "2026-09-06",
   "note": "created and verified against rfc-editor.org/rfc/rfc9728.html and rfc-editor.org/rfc/rfc8414.html (occupant-diff candidate)"
  }
 ],
 "id": "oauth-metadata-for-agents",
 "implementation": "multi-implementation",
 "last_verified": "2026-09-06",
 "name": "OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)",
 "native_status": "Internet Standard (RFC 8414, published June 2018) and Internet Standard (RFC 9728, published 2025); both are products of IETF consensus, not works in progress",
 "origin": {
  "date": "2018-06",
  "org": "IETF OAuth Working Group"
 },
 "part_of": null,
 "parties": [
  "agent-site"
 ],
 "phase": "stable",
 "probe": {
  "method": "GET",
  "on_absent": "Resource server does not publish RFC 9728 Protected Resource Metadata; an agent must fall back to a 401 response's WWW-Authenticate header (if present) or vendor-specific documentation to find the authorization server",
  "parse": "A JSON document per RFC 9728 with a 'resource' field and an 'authorization_servers' array; follow the first authorization_servers entry to {authorization_server}/.well-known/oauth-authorization-server per RFC 8414 to fetch endpoint and capability metadata",
  "path": "{resource_server}/.well-known/oauth-protected-resource"
 },
 "question": "How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?",
 "scope": "general",
 "spec_url": "https://www.rfc-editor.org/rfc/rfc9728.html",
 "step": "permit",
 "summary_md": "This record covers the pairing of RFC 8414 (OAuth 2.0 Authorization Server Metadata, published June 2018) and RFC 9728 (OAuth 2.0 Protected Resource Metadata, published 2025), as they are increasingly cited together as the discovery backbone for AI agent authorization, including by the MCP authorization specification and by newer conventions such as auth.md [1][2][3]. Both are mature, Internet Standards Track IETF RFCs, not agent-specific drafts — this record exists because their combination has become a de facto permit-discovery mechanism for the agentic web, not because either RFC was written with agents specifically in mind.\n\nRFC 8414 defines a JSON metadata document, conventionally at `/.well-known/oauth-authorization-server`, listing an authorization server's endpoints (authorization, token, etc.) and supported capabilities (grant types, scopes, PKCE support, and so on) so a client can configure itself without hardcoded assumptions [2]. RFC 9728, the newer companion, defines the resource-server side: a JSON document, conventionally at `/.well-known/oauth-protected-resource`, naming which authorization server(s) protect a given resource and what scopes it supports, closing the gap where a client encountering an unfamiliar API had no standard way to learn which authorization server to talk to [1]. Chained together — typically triggered by a 401 response whose `WWW-Authenticate` header names the Protected Resource Metadata URL — an agent can go from 'I got denied access to this API' to 'here is the authorization server and its capabilities' with two GET requests and no prior configuration [3].\n\nNeither RFC defines agent identity, delegation semantics, or content-use permissions; they are pure discovery/metadata mechanisms that any OAuth 2.0 client, human-driven or agentic, can use. This is why several of the newer, more agent-specific drafts in this dataset (auth.md, and indirectly DAAP and AAP, which build on standard OAuth server metadata rather than defining their own) lean on these two RFCs as their discovery layer rather than reinventing one.\n\nAs of this verification (2026-09-06), both documents are final, numbered RFCs on the Standards Track, so phase is stable and there is no version-in-flux to track. Implementation is recorded as multi-implementation on the strength of RFC 8414's seven-plus years of adoption across the OAuth ecosystem (essentially every major identity provider implements it) and RFC 9728's growing adoption for resource servers, including its explicit use in the MCP authorization specification. What is unresolved: this record does not independently measure what fraction of AI-agent-facing APIs specifically (as opposed to OAuth generally) publish RFC 9728 metadata; that would require a dedicated probe run against a domain sample of agent-facing services.",
 "track": "ietf",
 "version": {
  "date": "2025",
  "label": "RFC 8414 (2018-06) and RFC 9728 (2025)"
 },
 "url": "https://agenticweb.wiki/protocols/oauth-metadata-for-agents/",
 "category": "permit",
 "type": "protocol"
}