Hi Yaron, Thanks for the feedback, and no problem taking it to email. Answers inline.
*ID Token expiration* Yes, the ID Token used as a subject_token is validated against exp, and expired ID Tokens are rejected. The IdP's Token Exchange processing rules require assertion validation per RFC 7521 Section 5.2, which includes expiration. You are right that this makes the ID-Token-as-subject-token path narrow in practice, since ID Tokens are intended for one-time use by the OpenID RP and are typically short-lived. That is exactly why the draft also accepts a Refresh Token as subject_token: it lets the client refresh the ID-JAG without a fresh Identity Assertion round trip once the ID Token has expired. *Refresh Token rotation* The base draft does not currently mandate rotation on this exchange. It defers to standard OAuth semantics: RFC 6749 Section 10.4, and OAuth 2.1's stronger guidance, both call for refresh token rotation as a security best practice. IdP implementations SHOULD apply the same rotation policy they would for a normal refresh_token grant at the token endpoint. Is there a specific security consideration you were thinking of that warrants more explicit guidance in ID-JAG? *RAR in the Token Exchange* To be clear, this is by design rather than an accident. ID-JAG does not define an RAR profile of its own, and intentionally leaves the schemas, discovery, and validation of authorization_details to downstream profiles and deployment-specific arrangements. The base draft lets authorization_details flow through the Token Exchange request and the issued ID-JAG, and the IdP evaluates administrator policy for what to include, but the spec deliberately avoids baking in specific RAR type semantics because those belong to the Resource Authorization Server and the ecosystem it participates in. Your RAR Metadata draft slots directly into this composability model. If the Resource Authorization Server publishes its RAR types via a discoverable metadata endpoint with schema_uri and documentation_uri, the IdP can validate requested authorization_details against the RAS-published schemas, proxy the schema references into the ID-JAG so the RAS-side validation is consistent, and apply administrator-gated policy on which remote RASes are accepted and which types and scopes are permitted. That is exactly the composition ID-JAG's current shape anticipates. The real question, and where I would appreciate your input, is whether ID-JAG needs additional text to make this composition contract explicit. Specifically: - Which invariants ID-JAG guarantees at the Token Exchange and ID-JAG issuance boundaries. - What a composing RAR profile can assume about claim placement and error handling. - Which extension points (metadata parameters, error codes, discovery URLs) are already available versus what would need to be added. If your draft is going to sit alongside ID-JAG in real deployments, spelling out that composition contract would help both drafts move forward without one blocking the other. Could you sketch the composed flow end-to-end (Client → IdP with RAR discovery, IdP → RAS with proxied schemas)? That should surface the specific gaps in ID-JAG that would block the composition. With that concrete input, we can bring an issue to the ID-JAG working group. Best, Karl On Tue, Jul 21, 2026 at 11:57 PM Yaron ZEHAVI < [email protected]> wrote: > Dears, > > I’d like to provide some feedback and questions, and in view of the > limited time in the meeting chose to do it here. > > > > - When an ID token is used to request an ID-JAG, I assume its > expiration is evaluated so that expired ID tokens are rejected? If so and > considering limited ID token exp (in line with its intended usage to be > consumed once by an OpenID RP), this reduces this path's interoperability. > - I assume that’s why you’ve introduced refresh tokens as subject > tokens. When a refresh token is successfully used to obtain an ID-JAG, > should it be rotated? > - Including RAR in the ID-JAG token exchange request is a valid use > case, however it presents some challenges: > - The requested authorization_details are expected and enforced by > the resource domain (and its AS), but requested from the IDP AS and > their > request processing and inclusion is governed by its policies. > - How would the IDP AS publish supported authorization_details > types and their metadata, when it is actually acting as a proxy for the > Resource AS? > - Perhaps my draft (RAR Metadata and error remediation > <https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/>) > can support this use case: > - *Resource AS* could use the proposed RAR metadata endpoint to > publish metadata and schema of its RAR types: > > > - This allows *IDP AS* runtime enforcement of requested > authorization_details against *Resource AS’* published schemas. > - Furthermore, If *Resource AS* publishes metadata using *schema_uri > *and* documentation_uri*, then *IDP AS* may act as a proxy > pointing to *remote schemas* by reference, by including remote > uris. I assume this will require gating by an administrator to > configure > which remote Resource AS to accept as audience, which (scopes and) > RAR > types of theirs to support and which local policies govern their > processing. > > > > Regards, > > Yaron > 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] To unsubscribe send an email to [email protected]
