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]> 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]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
