[OAUTH-WG] Re: Feedback and questions to Identity Assertion JWT Authorization Grant

[Karl McGuinness <[e-mail]>]

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

>