Dear Justin, Thank you very much for taking the time to review my draft and provide such thoughtful and valuable feedback. It’s encouraging to hear that the core challenge resonates with you, especially given your long-standing and significant contributions to key RFCs.
Regarding the error response body (§5.1): I believe this point merits further discussion. The first revision of my draft encoded remediation content as base64 JSON within the WWW-Authenticate header. However, I later opted to use the response body instead due to several concerns: 1. Header Size Limits: Large header content risks truncation or dropping by proxies, routers, or browsers due to common header size restrictions, impacting reliability. 2. Caching and Replay Risks: Intermediaries may cache WWW-Authenticate responses, potentially causing reuse of stale information. 3. Exposure in Logs and Intermediaries: Headers are often logged or visible to intermediaries, increasing the risk of leakage or misuse. 4. Potential Header Stripping: Some network devices or middleware may strip or alter the WWW-Authenticate header, breaking the authentication flow. Recently, Yaroslav’s OAuth Transaction Authorization Challenge draft<https://www.ietf.org/archive/id/draft-rosomakho-oauth-txn-challenge-00.html> chose to return the challenge as a JWT in the WWW-Authenticate header. Both drafts could benefit from WG discussion on this topic to find a balanced approach. On the remediation mechanisms in §5.1–5.2: The draft proposes two remediation mechanisms: 1. RAR types metadata discovery: * Supports offline or just-in-time remediation, the latter may harness LLM capabilities to interpret metadata and construct required authorization details objects. * If required RAR types vary per resource (I’m checking with Rune Grimstad if HelseID is an example), this mechanism informs clients better than requiring the resource server to expose multiple RFC 9728 resource metadata endpoints per requirement set. Such a workaround would not work well in MCP server use-cases where the resource URL remains constant and required tools are specified in the JSON-RPC body. 2. Actionable RAR request objects derived from the request’s input: * Alleviates clients from learning to construct valid authorization details objects. * Leverages the resource server’s domain knowledge to provide clients with actionable authorization details request objects based on the failing request’s input. * If I had to choose the most valuable component of this draft, it would be this mechanism. It enables streamlined remediation and forms the basis of MCP’s SEP-2643<https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2643>. * Note: A similar remediation mechanism is used in Yaroslav’s draft. Regarding the “authorization hint” in §5.2: The authorization hint aims to help clients identify an existing access token associated with equivalent authorization details, without requiring semantic understanding of the authorization details request object. It is somewhat analogous to GNAP’s resource_reference, but should remain stable when semantically similar authorization details are returned by the resource server. I fully agree that clients should not inspect token values. However, during a specific end-user session, clients may hold multiple valid tokens. This implies clients need to persist all valid tokens and select the correct one. Assuming clients manage a “token bag” with entries like: TokenEntry { issuer: string, access_token: string, expires_in: number, audience: string, scopes: Set<string>, authorization_hint: RS-provided hint or client-calculated fingerprint (hash of canonical representation) } Clients don’t need to evaluate tokens or RAR request objects. Instead, the resource server returns actionable RAR request objects along with a stable authorization hint string. The client looks for a matching token by hint; if none is found, it requests a new token. The resource server should omit the authorization hint when the token is intended for single-use. This approach stems from discussions in the MCP Fine-Grained Authz WG<https://docs.google.com/document/d/1X4q8qVazt2MIuLs2kMpAqJn5rlyYnBGk0FLw2a9D-yU/edit?tab=t.0>, and was presented by my colleague Henrik Kroll at OSW 2026. I welcome discussion on whether this challenge is acknowledged, if the proposed mechanism is acceptable, and how best to specify it. Also, whether GNAP or its concepts can be applied here. On RS Processing Rules: These can certainly be trimmed. More important, in my view, is that authorization servers issuing JWT access tokens with authorization_details support configuring a cutoff size for approved RAR objects. Beyond this size, the JWT should omit the authorization_details claim, making approved RAR objects available through token introspection. Regarding multi-tiered RAR schema discovery: The first two steps (calling RS metadata to discover AS, then calling AS metadata) are standardized. Steps 3 and 4 could be skipped by including RAR metadata in the RFC 8414 authorization server metadata document. The draft initially proposed this but moved RAR metadata to a separate endpoint to avoid overloading the highly used main metadata document with less commonly used and verbose RAR metadata. This tradeoff certainly merits WG discussion. On RAR discovery for the RS: In the actionable RAR objects remediation use case, the RS identifies the access token issuer and provides actionable RAR objects. However, if multiple authorization servers support the required RAR types, the RS cannot simply point to a single schema. This is why Boolean logic is intended: for example, a token obtained from social login may not fulfill the resource’s requirements, which instead require an eIDAS-approved RAR type offered by any member state’s AS. In such cases, where multiple options exist and the RS lacks knowledge of client or end-user preferences, it seemed best to provide the required RAR types and let the client decide which AS and RAR types to use. Thank you again for your insightful review. I look forward to continuing this discussion. Regards, Yaron Classification: GENERAL From: Justin Richer <[email protected]> Sent: Monday, June 29, 2026 11:30 PM To: oauth <[email protected]> Cc: Judith Kahrer <[email protected]>; Yaron ZEHAVI <[email protected]> Subject: Re: [OAUTH-WG] Request for review of draft-zehavi-oauth-rar-metadata This message is from an external sender - be cautious, particularly with links and attachments. Hi everyone, I finally got a chance to sit down and read through this doc. It’s got some good ideas in here and I’d like to separate out what I see as a few loosely-coupled items in there that I think we as a WG could handle differently. I do think the doc is worth discussing, and there are some useful and interesting things at play here. 1) insufficient_authorization_details error message (§5). This is a simple one, and it makes sense to have something along the lines of insufficient_scope here. I think we can bike shed what to call it. 2) The error response body (§5.1). This is I think a bridge too far and we should not adopt anything of this nature — since this is coming from the RS, the response body is owned by whatever API is being protected there. This is why we didn’t put an RS response body in 6750 — it just says “return the error code” without any real indication of how to do that. That was on purpose, if a bit awkward in practice. Importantly, this isn’t the same as the error codes from the AS where we DO have full control over the response. 3) This means that all of the detail (in §5.1-5.2) of how to explain which types are needed and the boolean logic around them is, in my opinion, not particularly useful. Furthermore, it’s generally expected that the `type` value isn’t going to vary a whole lot from a given API endpoint, in most cases, so just giving me a complex engine to give a boolean combination of types is kinda useless. MCP, being a proxy, might change that expectation a bit, but that can be better handled at the MCP layer and not at the OAuth layer. I agree that this is a hard problem to solve. 4) The “authorization hint” in §5.2 is wildly underspecified — how is the opaque value “matched” to a token? The client isn’t supposed to look at the value of tokens at all. 5) Some of the discovery mechanics in §5.2 is a bit reminiscent of GNAP’s “resource set registration” function (https://www.rfc-editor.org/info/rfc9767/#name-registering-a-resource-set) what was in turn uplifted from UMA2, Namely here the RS can trade a complex RAR-style object for a scope-style string to give the client. In GNAP this is native, here we could explicitly map it back to a `scope` value as a possible method of transmission. 6) the RS Processing Rules are likewise too opinionated about what an RS ought to do. OAuth does not solve a cold-boot ecosystem, and so an RS is going to do whatever it was set up to do, full stop. That could mean introspecting, it could mean parsing the token, it could mean reading a DB table, it could mean ignoring everything entirely (not recommended, but I’ve seen it in production, hah!). Regardless, this is a line of interop that OAuth has historically not been keen to cross. 7) I don’t quite understand the need for the multi-tiered RAR schema discovery from the AS side. As it stands right now, if I’m a client doing a discovery call, I might have to call (a) the RS discovery endpoint to find (b) the AS discovery endpoint to find (c) the RAR details endpoint to find (d) the RAR schema endpoint for whatever bit I care about. This seems needlessly layered, what is the benefit for separating things like this? 8) I don’t see discussion of RAR discovery for the RS, apart from the error code list. Couldn’t we just point to a defined RAR schema from the RS’s error response header and call it? All said there are a lot of parts here that don’t quite play together, but some good thinking that warrants further discussion by the WG. At the very least, it’s probably time we tackle RS error semantics for RAR protected endpoints and decide how deep down that rabbit hole we really want to go. — Justin On Jun 14, 2026, at 6:07 PM, Yaron ZEHAVI <[email protected]<mailto:[email protected]>> wrote: Dear OAuth Working Group, I would like to reach out once more to request additional review and feedback for this draft: https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/ The document addresses a practical interoperability challenge around Rich Authorization Requests (RAR): discovery of metadata for authorization details types, allowing clients dynamic discovery rather than relying on out-of-band agreements. It also standardizes error signaling in case insufficient RAR was provided and offers structured ways of remediation. Draft -04 addresses feedback kindly provided by @Judith Kahrer<mailto:[email protected]> about clearer processing rules and resource server providing required RAR types alongside a WWW-Authenticate error caused by insufficient rar. The draft was presented at IETF 125 and OSW 2026, where it received positive feedback, and is already seeing interest and adoption across real-world deployments, including: • Norway's HelseID healthcare identity platform • Raiffeisen Bank Romania • The Model Context Protocol (MCP) Fine-Grained Authorization Working Group (see SEP-2643) This demonstrates the need for a standardized mechanism for RAR capability metadata discovery. We would greatly appreciate additional feedback. Best regards, Yaron Zehavi This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien). Classification: GENERAL _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
