Yaron, Thanks for the detailed walkthrough. Responses on the two parts.
*Input tokens.* Filed #115 <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/115> with the rationale in detail. An access token may contain identity claims, but it is not an identity assertion for the client. Its primary contract is authorization to a resource. OIDC introduced the ID Token because OAuth access tokens were intentionally not suitable as a portable authentication artifact. Similar questions have come up across several ID-JAG, XAA, and MCP Enterprise-Managed Authorization threads. Would appreciate your view on #115 <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/115> so we can consolidate the discussion in one place rather than in parallel. On draft-gerber-oauth-deferred-token-response <https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/> and refresh token rotation: haven't dug into issue #10 yet. Will follow up there rather than in this thread. *RAR in ID-JAG.* Your walkthrough matches how I'd expect an IdP product to operationalize this. Your draft is where the productization scaffolding lives. Reference architectures and best practices are the layer that operationalizes it across deployments. Governance policies attached to imported RAR type schemas is directly analogous to how IdPs today import role and entitlement definitions via SCIM and then apply governance to their issuance during JIT access, access request and approval workflows, and provisioning processes. Same shape, different artifact. Related: I've added support for draft-zehavi-oauth-rar-metadata in the editor's draft of draft-mcguinness-token-xchg-target-svc-disco <https://mcguinness.github.io/draft-mcguinness-token-xchg-target-svc-disco/draft-mcguinness-token-xchg-target-svc-disco.html> (OAuth 2.0 Token Exchange Target Service Discovery). It can act as an IdP-side catalog for XAA, similar to SSO dashboards in IdPs today. Your draft describes authorization detail types server-wide, this one reports per-subject Token Exchange Target eligibility. Would appreciate your feedback before the next version is published. For JIT specifically, draft-mcguinness-oauth-insufficient-claims <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-insufficient-claims/> and ID-JAG issue #83 <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/83> propose an insufficient_identity_claims error and required_claims negotiation to close the interop gap between what a RAS needs for account resolution and what the IdP-issued ID-JAG carries. Would appreciate your feedback on #83 <https://github.com/oauth-wg/oauth-identity-assertion-authz-grant/issues/83>. There's likely alignment worth exploring with your RAR metadata approach. Between your draft-zehavi-oauth-rar-metadata <https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/>, draft-gerber-oauth-deferred-token-response <https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/> , draft-parecki-oauth-jwt-grant-interaction-response <https://datatracker.ietf.org/doc/draft-parecki-oauth-jwt-grant-interaction-response/>, and draft-rosomakho-oauth-txn-challenge <https://datatracker.ietf.org/doc/draft-rosomakho-oauth-txn-challenge/>, there's a rich substrate that composes with ID-JAG for discovery, challenge, and approval / remediation flows around fine-grained access and governance. I haven't seen anything in your walkthrough that requires changes in the ID-JAG spec itself. The composition seems to work on top of what's already there. Let me know if I missed anything, and feel free to open GH issues for any gaps you identify that would touch invariants in the spec. Thanks again for the write-up. -Karl >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
