Dear Karl, Thank you for this kind and detailed response. > Observations on input tokens:
Acknowledging the ID token limited interoperability discussion and considering access tokens are also an “Identity Assertion” of the end-user, is there any reason the draft accepts refresh tokens but not access tokens? As for refresh token rotation, I think relying on the specs mentioned is a solid approach. I brought up the rotation point since it was discussed this week about DTR (see issue #10<https://github.com/maxwellgerber/deferred-token-response/issues/10>). Therefore I was wondering if refresh token rotation is handled similarly across these 2 drafts. > RAR in ID-JAG I’ll try to take a shot at it 😊 ID-JAG enables policy-led decisions to govern back-channel requests. Therefore, I’d assume the e2e flow begins when IdP defines a RAS as audience it accepts. I would assume at this point an explicit allow would be required and at that this point in time policy is defined for that RAS, with thought given to which scopes and RAR types may be requested and the authorization policies that govern their provision into JAGs. RAS setup on IdP At this point RAS’ RAR types need to be setup on IdP and associated to governing policies. If RAS provides out of band RAR documentation (doesn’t support my draft), this process will likely be manual. If RAS does provide RAR-Metadata as described in my draft, metadata import into IdP can be streamlined. However way the IdP acknowledges RAS’ RAR types, it needs to associate them with policies. These may be as fine-grained and content-sensitive as supported by the RAR type’s schema (some schemas define constraints and enumerations better than others). For example, for the imaginary RAR type “jira_ticket_authority”, which has an imaginable attribute “actions”, accepting an array of 1..4 string enums: [read / create / modify / delete]; IdP may define a policy requiring additional user / departmental approval if actions include “delete”. Maintaining IdP governance policies’ freshness IdP should detect and respond to change in RAS RAR type schemas its governance policy apply to, and upon change trigger a policy update & review task. If RAS doesn’t support my draft, this task requires out of band agreements. However if RAS does, it can be automated: IdP can periodically check and detect RAS RAR type metadata has changed and trigger required policy review tasks. IdP publishing supported (proxied) RAR types Clients of IdP need to discover which RAR types are supported and how to construct them. I assume IdP’s AS metadata needs to include RAS’ RAR types, and IdP’s authorization_details_types_metadata_endpoint should advertise RAS’ RAR types schema. This can be done by reference in case RAS uses schema_uri and documentation_uri. Client makes ID JAG request to IdP including RAR IdP should: * Validate RAR contents matches up-to-date type schema, reject if it doesn’t on interoperability grounds. * Apply governance policies possibly including fine-grained policies evaluating requested RAR contents. * Contact end-user (IdP’s forte) or other approvers as deemed necessary. Client makes token request to RAS using ID-JAG which contains RAR RAS validates requested RAR matches its schema. Note – header size is not a limitation here, as the request is delivered in HTTP body, so verbose RAR may be included. I hope this is helpful and appreciate the invitation to think about this challenge. Yaron Classification: GENERAL From: Karl McGuinness <[email protected]> Sent: Wednesday, July 22, 2026 8:39 PM To: Yaron ZEHAVI <[email protected]> Cc: Aaron Parecki <[email protected]>; [email protected]; Brian Campbell <[email protected]>; oauth <[email protected]> Subject: Re: Feedback and questions to Identity Assertion JWT Authorization Grant This message is from an external sender - be cautious, particularly with links and attachments. 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]<mailto:[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: [cid:[email protected]] * 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 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]
