[OAUTH-WG] Re: Request for review of draft-zehavi-oauth-rar-metadata

[Yaron ZEHAVI <[e-mail]>]

Dear Judith,
Thanks for taking the time to review and for the positive feedback.
The nits and typos I corrected, thanks for noticing.

As for the discussion points:

  1.  A separate metadata endpoint was proposed by one of the first reviewers, I think it was Rune Grimstad of HelseID. It made sense as RAR schemas and additional documentation’s sheer size would far exceed AS metadata, making AS metadata cumbersome to read. It seemed to justify a dedicated endpoint.
  2.  The 2nd approach was not intended to provide metadata but rather the actionable RAR objects, lifting from clients the burden of learning to construct valid RAR objects. We have this use case in banking as we have many clients per resource server, and the idea is that resource endpoints (e.g POST /payments) fail when RAR is insufficient, but they provide an actionable remediation path (Bob wanted to pay Alice 50$, so here’s the RAR object to allow it). However, you do raise a good point about the difference between supported vs required. However when reading RFC 9728 description of scopes_supported claim, it actually means which scopes are required to access a resource. But, since the RAR requirements may differ per resource, fully using the propsosed authorization_details_types_required attribute requires a resource server to support multiple resource metadata endpoints (per resource endpoint), which might be a lot to ask (and is discouraged by MCP’s JSON-RPC style). However, I take a good idea from your feedback: perhaps a resource server should provide the specifically required RAR types for failing resource, in the HTTP body. I’ll be happy for additional feedback on this point.
  3.  The WWW-Authenticate new error code insufficient_authorization_details was modelled after RFC 6750’s insufficient_scope error code, which is returned with HTTP 403 error code. Looking into RFC 9110: “403 Forbidden (§15.5.4): the server understood the request but refuses to fulfill it. If authentication credentials were provided, the server considered them insufficient”, which I think matches the scenario well.
  4.  The motivation is to remain with JWT tokens when that’s the token type of choice, as opaque tokens can make issuer discovery more difficult for resource servers that accept tokens from multiple authorization servers because the token value itself typically does not reveal which authorization server issued it.

Regards,
Yaron



Classification: GENERAL
From: Judith Kahrer <judith.kahrer=[e-mail]>
Sent: Friday, June 5, 2026 2:12 PM
To: Yaron ZEHAVI <[e-mail]>
Cc: oauth <[e-mail]>
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 Yaron,

I had a look at the draft. I think it really closes a gap in the OAuth framework, and I am overall positive .

There are some details and decisions that I do not completely follow.

You suggest a authorization_details_types_metadata_endpoint that lists the authorization details types that the authorization server supports. What's the rational behind adding a new endpoint compared to adding the types (schemas) to the authorization server metadata?



You also describe two approaches on how to discover which authorization details types a client should add in its request:
- The resource server publishes the required types in its resource server metadata.
- The resource server adds the required type in an error response.

I'm a bit reluctant to the first approach because traditionally, metadata contains data about the supported features not the required. I think that the second approach is better and should be the only one. I understand, that there are limits in your current suggestion in cases where authorization servers do not support the same authorization details type required by the client. Still, I think, the error response from the resource server is a better place to define the requirements than the metadata. Maybe there is a good way to add the expression in the response?

Regarding the error response, I noticed that you use the 403 HTTP code in the protocol. Personally, I think 403 + WWW-Authenticate makes sense.

403 + challenge with Bearer scheme communicates to the client: “I understand the token but the token is insufficient for the request. Changing the credentials may change my mind.”,
Similarly, 401 Bearer scheme communicates: “The token is not valid for the target resource. Get a new token and try again.”

The distinction between “not sufficient” and “not valid” is more or less philosophical imo.
However, I have learned at OSW that 401 is the more established and thus preferred pattern for challenges (and the one listed in RFC 9110/STD 97: HTTP Semantics). You probably should change to 401.

When it comes to JWTs becoming too big because of the authorization details, Introspection is the way to go as you correctly point out. However, I think that this phrase is misleading: "If the size exceeds this threshold, JWT access tokens SHALL NOT include the authorization_details claim; instead, approved authorization details will be accessed via token introspection." I read it like JWT access tokens should be introspected which is not a common pattern. I suggest you rephrase your guidance. Maybe require the authorization server to return opaque tokens instead?

Best regards,
Judith

---
P:S: Some nits/typos::



Abstract:

In second paragraph, line #54, “tp” should be “to”: […] allowing clients [tp -> to] dynamically discover metadata […]



Introduction

List: Each bullet point should complement the phrase “this document defines”. Remove “adds” from the second bullet point, and add “a” at the beginning the last (A recommended handling of). You could also move the recommended handling of large authorization details objects to a separate paragraph.

Simplify: “The optional providing of actionable authorization details objects by resource servers enables:” (line 73)

Suggested update: Providing actionable authorization details objects in the error response from the resource server enables:

Rational:  The subject of the sentence, “the optional providing of actionable authorization details objects by resource servers”, makes the sentence hard to read imo. “providing actionable authorization details objects by resource servers” describes an act done by the resource servers (passive voice). Often, the meaning of a sentence is more clear with an active voice. Also the fact that the provision is optional, is not relevant for its benefits.

On Thu, Jun 4, 2026 at 12:18 PM Judith Kahrer <[e-mail]<mailto:[e-mail]>> wrote:
Hi Yaron!

I'll have a look and get back to you with some thoughts. From what you write in your mail and from what I have heard, it sounds like an interesting draft indeed! I look forward to studying it in more detail.

Best regards,
Judith


On Wed, Jun 3, 2026, 22:37 Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:[e-mail]>> wrote:
Dear OAuth Working Group,
I would like to request your 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.

The draft was presented at IETF 125 and OAuth Security Workshop (OSW) 2026, where it generated valuable discussion and received positive feedback, which has been incorporated into the latest revision of the draft.

Importantly, the draft 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<https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2643>)

These deployments and positive feedback demonstrate the need for a standardized mechanism for RAR capability discovery and metadata publication.
Given the willingness to adopt the proposal and positive feedback from the community, we’d like to ask the Working Group to consider its adoption.
We would greatly appreciate additional review, feedback, and discussion from OAuth WG participants.

Thank you for your consideration.

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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
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).