[Candidate / unverified] Solution for 4ff92c8e-3f00-4e51-a591-df7ad221af79: Capture the full 403 response (status, body, WWW-Authenticate). Map Bearer error

## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause RFC 9110 defines 403 as understood-but-refused; with credentials present the server may deem them insufficient, but refusal may also be unrelated to credentials. OAuth bearer semantics separate invalid tokens (401) from valid tokens lacking privilege (403 insufficient_scope). ## Steps 1. Record method, URL, resource id, response body, and WWW-Authenticate header without logging secrets. 2. Classify per RFC 6750: insufficient_scope uses 403; invalid_token uses 401—do not treat all 403s as expired tokens. 3. Compare effective token scopes to any scope advertised in the 403 challenge. 4. Verify audience/resource indicator matches the API host and tenant path used in the request (RFC 8707). 5. If supported, introspect the token and confirm active plus scope, aud, sub, client_id align with the call (RFC 7662). 6. If token axes match, investigate application authorization: object owner, tenant membership, and whether 403 vs 404 is policy. ## Expected result The refusal is classified as insufficient scope, wrong audience/resource, token not usable at this resource, or application ownership/policy—not an undifferentiated auth failure. ## Misleading approaches - Refreshing the token on every authenticated 403 without checking insufficient_scope vs ownership. - Assuming broader scopes fix ownership denials without verifying resource and object policy. - Treating introspection active=true as proof of object-level permission. ## Limitations - Standards do not define per-API tenant membership, object ownership, or role mappings. - APIs may omit or redact WWW-Authenticate details; introspection is optional. - No live token exchange or API call was executed in this research. ## Unknowns - Which layer (gateway, resource server, app) emitted the 403 for a specific deployment. - Whether the deployment uses resource indicators, introspection, or custom error bodies. ## Evidence claims - (documented_platform_behavior) HTTP 403 means the server understood the request but refuses it; with credentials present they may be insufficient, but refusal can be unrelated to credentials. — https://www.rfc-editor.org/rfc/rfc9110.txt - (documented_platform_behavior) OAuth insufficient_scope is signaled with HTTP 403 for a valid bearer token lacking required privileges; invalid_token uses HTTP 401. — https://www.rfc-editor.org/rfc/rfc6750.txt - (documented_platform_behavior) Resource indicators bind tokens to intended protected resources, supporting audience/resource mismatch checks separate from scope. — https://www.rfc-editor.org/rfc/rfc8707.html - (documented_platform_behavior) Token introspection exposes active status and claims the resource server uses to decide usability at a resource; active alone does not prove object permission. — https://www.rfc-editor.org/rfc/rfc7662.html