Hi Chris, I want to understand your thoughts a bit better. It would really help to see a Mermaid diagram of it. You can create one here: https://mermaid.live
Thanks, Atul On Mon, Feb 9, 2026 at 4:49 PM Chris Keogh <[email protected]> wrote: > No worries Karl, I thought as much but thought I'd pipe up anyway. > > Thanks 🙏🏼 > > On Tue, 10 Feb 2026 at 13:21, Karl McGuinness <[email protected]> > wrote: > >> @Chris, I think this topic might be more relevant to the OpenID Connect >> A/B working group (https://openid.net/wg/connect/) as it appears to be a >> SSO use case. The OpenID Native SSO spec ( >> https://openid.net/specs/openid-connect-native-sso-1_0.html) supports 1 >> type of flow and vendors such as Okta support Mobile to Web SSO >> https://developer.okta.com/docs/guides/native-to-web-sso/main/ using >> proprietary mechanism. There are a lot of security considerations/caveats >> with this type of flow that would be best answered in the OIDC WG. >> >> -Karl >> >> On Mon, Feb 9, 2026 at 1:17 PM Chris Keogh <[email protected]> >> wrote: >> >>> Hi there all, >>> >>> I'm dealing with a similar scenario that Tarun is highlighting and >>> thought I'd chime in to make it more concrete. >>> >>> We have a mobile application and a web application that both use the >>> same IdP/AS. The mobile client (public+PKCE) uses long lived refresh tokens >>> and only requires the user to log in once (via the system browser) to >>> retrieve the access/refresh token combination. From this point on the user >>> is considered signed in to the mobile application, but the session at the >>> IdP will quickly expire (and the session/auth cookie in the system browser >>> with it). >>> >>> We'd like to be able to embed web views within the mobile application >>> that are hosted by our web app without the user having to sign in again. >>> >>> I've been thinking about using something along the lines of Identity >>> chaining or JWT authorization (with DPoP) to retrieve one time use short >>> lived access tokens that can be used by the mobile client to query an >>> endpoint which signs the user in and returns the contents of the IdP >>> session cookies to the mobile application, which then injects the cookies >>> into an embedded browser (not the system browser) which then loads the web >>> view which goes through the standard auth code flow. >>> >>> As Tarun points out, it feels like there's a gap in the standards where >>> this kind of thing isn't really addressed. Potentially it's more of an OIDC >>> problem? >>> >>> >>> On Tue, 10 Feb 2026 at 03:54, <[email protected]> wrote: >>> >>>> Send OAuth mailing list submissions to >>>> [email protected] >>>> >>>> To subscribe or unsubscribe via email, send a message with subject or >>>> body 'help' to >>>> [email protected] >>>> >>>> You can reach the person managing the list at >>>> [email protected] >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of OAuth digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Feedback on ID-JAG same IdP prohibition - Application to >>>> Application Delegation >>>> (Pieter Kasselman) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Mon, 9 Feb 2026 14:53:14 +0000 >>>> From: Pieter Kasselman <[email protected]> >>>> Subject: [OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition - >>>> Application to Application Delegation >>>> To: Tarun Nanduri <[email protected]> >>>> Cc: Brian Campbell <[email protected]>, >>>> [email protected] >>>> Message-ID: >>>> < >>>> caltwoa1kwhq8dibta9j52gcgqhnhqgel+owfjy9sjl_dpiq...@mail.gmail.com> >>>> Content-Type: multipart/alternative; >>>> boundary="0000000000000d50df064a654dc1" >>>> >>>> Hi Tarun, for the original use case you described, you may want to >>>> consider >>>> the transaction token spec [1]. >>>> >>>> It was specifically developed to allow authorization context, including >>>> user and workload/microservice identity information, to be passed >>>> between >>>> microservices within a domain, without having to pass around access >>>> tokens. >>>> >>>> Cheers >>>> >>>> Pieter >>>> >>>> [1] >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/07/ >>>> >>>> On Sun, Feb 8, 2026 at 8:02 AM Tarun Nanduri <[email protected]> >>>> wrote: >>>> >>>> > Hi Pieter, Brian, Aaron, and the WG, >>>> > >>>> > Thanks for the feedback and for taking the time to look at this. I’ve >>>> been >>>> > thinking over the points about Section 8.3 and the general intent of >>>> ID-JAG. >>>> > >>>> > Stepping back from the specific spec for a second, it feels to me >>>> like we >>>> > have a bit of a gap in the OAuth/OIDC specifications. We’re >>>> essentially >>>> > looking for a standard way to do Directed Session Transfer, in >>>> environments >>>> > where shared cookies/SSO just aren't an option for security reasons. >>>> > >>>> > You pointed toward the Identity Chaining Across Domains draft as the >>>> > intended home for this, and I see the logic—since the AS in Domain A >>>> > generates the JWT grant, it handles the "identity proof" part of the >>>> > handover. >>>> > >>>> > But right now, if I want to move a user from App A to App B without a >>>> > fresh login, the options still feel a bit thin: >>>> > >>>> > - Standard SSO is off the table because of the "no-shared-cookie" >>>> > constraint. >>>> > - RFC 8693 is a great building block, but it’s mostly used for >>>> > service-to-service backend swaps. There isn't really a >>>> front-channel >>>> > "profile" for this (as RFC863 sends back a usable token rather >>>> than an >>>> > assertion). >>>> > - Identity Chaining, as Brian mentioned, is explicitly a >>>> specification >>>> > for cross-domain use. >>>> > >>>> > >>>> > It feels a bit ironic that the protocol makes "Cross-Domain" identity >>>> > transfers standardized via ID-JAG (as an OAuth native grant), but >>>> leaves >>>> > "Intra-Domain" delegation as a "roll-your-own" exercise. Without a >>>> standard >>>> > profile for this, people might just end up building non-standard hacks >>>> > which is exactly what we’re trying to avoid. >>>> > >>>> > I’m not trying to force a change to ID-JAG if the WG feels it’s the >>>> wrong >>>> > home, but I am curious: >>>> > >>>> > - Do we think this "Directed Session transfer" pattern is a gap >>>> worth >>>> > filling? >>>> > >>>> > It feels to me like there should be an "OAuth-native" way to do this >>>> that >>>> > has the right guardrails (audience binding, act claims, etc.) to make >>>> it >>>> > secure in a Zero Trust setup, but is as straightforward to implement >>>> as a >>>> > basic Auth Code grant. I’d love to hear if anyone else sees this gap, >>>> or if >>>> > there's a pattern I’m missing that doesn't involve a lot of custom >>>> "glue" >>>> > code. >>>> > >>>> > Best Regards, >>>> > Tarun Nanduri. >>>> > >>>> > On Thu, Feb 5, 2026 at 6:14 PM Pieter Kasselman >>>> <[email protected]> >>>> > wrote: >>>> > >>>> >> Hi Tarun >>>> >> >>>> >> I agree with Brain and Aaron that your use case can likely be >>>> addressed >>>> >> by the Identity and Authorization Chaining Across Domains draft [1]. >>>> You >>>> >> could always profile it further if needed. Is there a reason you >>>> would not >>>> >> be able to use that draft? >>>> >> >>>> >> Cheers >>>> >> >>>> >> Pieter >>>> >> >>>> >> [1] >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ >>>> >> >>>> >> On Wed, Feb 4, 2026 at 9:31 PM Brian Campbell <bcampbell= >>>> >> [email protected]> wrote: >>>> >> >>>> >>> Hi Tarun, >>>> >>> >>>> >>> As Aaron mentioned there are less tightly profiled variations of >>>> this >>>> >>> general flow, like oauth-identity-chaining >>>> >>> < >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/> >>>> >>> or rfc8693 <https://datatracker.ietf.org/doc/html/rfc8693> + >>>> rfc7523 >>>> >>> <https://datatracker.ietf.org/doc/html/rfc7523> together directly, >>>> that >>>> >>> don't have the same constraint regarding the IDP not issuing access >>>> tokens >>>> >>> in response to an ID-JAG it issued itself. Perhaps that might meet >>>> your >>>> >>> needs? Although those are intended for cross domain as well. >>>> Honestly, much >>>> >>> of this seems like more than is needed for a same idp / same domain >>>> case. >>>> >>> >>>> >>> On Tue, Feb 3, 2026 at 8:13 PM Tarun Nanduri < >>>> [email protected]> >>>> >>> wrote: >>>> >>> >>>> >>>> Dear Aaron, >>>> >>>> >>>> >>>> I am awaiting your feedback on this. To summarize, >>>> >>>> >>>> >>>> When an Identity Provider (IdP) does not support Single Sign-On >>>> (SSO) >>>> >>>> due to the nature of the systems involved, and a user needs to >>>> transfer >>>> >>>> their session to another application without re-logging in, I feel >>>> ID-JAG >>>> >>>> offers a secure and seamless solution, providing a smooth user >>>> experience. >>>> >>>> >>>> >>>> The RFC, as stated in previous emails, explicitly prohibits using >>>> the >>>> >>>> specification within the same IdP. Considering the zero-trust model >>>> >>>> typically applied within the same IdP, are we open to modifying the >>>> >>>> specification to allow its implementation within such environments? >>>> >>>> >>>> >>>> Best Regards, >>>> >>>> Tarun Nanduri. >>>> >>>> >>>> >>>> On Fri, Dec 5, 2025 at 8:46 AM Tarun Nanduri < >>>> [email protected]> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Hi Aaron, >>>> >>>>> >>>> >>>>> Thanks for the response, and pointing me to the Identity Chaining >>>> >>>>> draft. However, after looking at it, I don't think it applies to >>>> the >>>> >>>>> use-case I shared above (please feel free to correct here). It >>>> looks like >>>> >>>>> it's designed for cross-domain scenarios* whereas the use-case I >>>> >>>>> shared above has*, >>>> >>>>> >>>> >>>>> - Both the clients are in same trust domain >>>> >>>>> - We have single authorization server (it's the IdP too) >>>> >>>>> >>>> >>>>> The challenge we are trying to solve is, >>>> >>>>> >>>> >>>>> - Client A needs to transfer user session to client B >>>> >>>>> - WITHOUT Client A sharing its access token with client B >>>> >>>>> (security risk due to token exposure, invalid audience, >>>> unnecessary >>>> >>>>> privileges etc.) >>>> >>>>> - Both clients trust the same IdP >>>> >>>>> >>>> >>>>> This is why we're intending to use RFC8693, but it still requires >>>> >>>>> client A to send access token (after token exchange) to client B >>>> which >>>> >>>>> creates exposure we're trying to avoid. The ID-JAG pattern >>>> (cryptographic >>>> >>>>> proof of identity, not a usable token) would be perfect, except >>>> the >>>> >>>>> prohibition defined in section 8.3 of Identity Assertion draft: >>>> >>>>> 8.3. >>>> >>>>> < >>>> https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#section-8.3 >>>> >Cross-Domain >>>> >>>>> Use >>>> >>>>> < >>>> https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-cross-domain-use >>>> > >>>> >>>>> >>>> >>>>> This specification is intended for cross-domain uses where the >>>> Client, >>>> >>>>> Resource App, and Identity Provider are all in different trust >>>> domains. In >>>> >>>>> particular, the Identity Provider MUST NOT issue access tokens in >>>> >>>>> response to an ID-JAG it issued itself. Doing so could lead to >>>> >>>>> unintentional broadening of the scope of authorization. >>>> >>>>> My question remains, Can the section 8.3 prohibition be satisfied >>>> with >>>> >>>>> enough security controls (scope validation, replay prevention >>>> etc.) for >>>> >>>>> same IdP scenarios, or is it a hard limitation? >>>> >>>>> >>>> >>>>> Thanks and Regards, >>>> >>>>> Tarun Nanduri. >>>> >>>>> >>>> >>>>> >>>> >>>>> On Fri, Dec 5, 2025 at 1:53 AM Aaron Parecki <[email protected]> >>>> >>>>> wrote: >>>> >>>>> >>>> >>>>>> Hi Tarun, >>>> >>>>>> >>>> >>>>>> It sounds like what you are looking for is the parent draft of >>>> this >>>> >>>>>> draft, Identity and Authorization Chaining Across Domains: >>>> >>>>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ >>>> >>>>>> >>>> >>>>>> The document that defines the ID-JAG, Identity Assertion >>>> >>>>>> Authorization Grant, is a special case of Identity Chaining >>>> where both the >>>> >>>>>> client and resource have a pre-existing relationship with the >>>> same IdP. So >>>> >>>>>> I don't view it as a limitation, it's actually an optimization >>>> when there >>>> >>>>>> is a common IdP. The Identity Chaining draft is the same as this >>>> draft >>>> >>>>>> except it doesn't specify the input token format or the reason >>>> why the >>>> >>>>>> client and resource trust the cross-domain JWT issuer. >>>> >>>>>> >>>> >>>>>> Aaron >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Mon, Dec 1, 2025 at 8:11 AM Tarun Nanduri < >>>> [email protected]> >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>>> Dear OAuth Working Group & Aaron, >>>> >>>>>>> >>>> >>>>>>> I would like to provide feedback on the OAuth Identity Assertion >>>> >>>>>>> Authorization Grant (ID-JAG) specification, specifically >>>> regarding >>>> >>>>>>> the prohibition against same-IdP usage. >>>> >>>>>>> >>>> >>>>>>> Use Case: >>>> >>>>>>> >>>> >>>>>>> In microservices architectures using the same IdP, there is a >>>> >>>>>>> legitimate need for service-to-service identity delegation >>>> WITHOUT >>>> >>>>>>> sharing access tokens directly: >>>> >>>>>>> >>>> >>>>>>> - Application A has a user-scoped token >>>> >>>>>>> - Application A needs to invoke Application B on behalf of user >>>> >>>>>>> - Sharing Token A with Application B creates security risks: >>>> >>>>>>> * Token exposure between services >>>> >>>>>>> * Replay attacks >>>> >>>>>>> * Over-privileged access >>>> >>>>>>> * Audience mismatch >>>> >>>>>>> >>>> >>>>>>> The Gap: >>>> >>>>>>> >>>> >>>>>>> ID-JAG's assertion pattern solves this perfectly: >>>> >>>>>>> - Application A creates a cryptographic identity assertion >>>> >>>>>>> - Assertion is audience-bound to Application B >>>> >>>>>>> - Application B exchanges assertion for its own token >>>> >>>>>>> - No credential sharing between services >>>> >>>>>>> >>>> >>>>>>> However, the same-IdP prohibition prevents this legitimate use >>>> case. >>>> >>>>>>> >>>> >>>>>>> Suggestion: >>>> >>>>>>> >>>> >>>>>>> Consider either: >>>> >>>>>>> 1. Removing the same-IdP prohibition with appropriate security >>>> >>>>>>> guidance >>>> >>>>>>> 2. Adding an exception for service-to-service delegation >>>> scenarios >>>> >>>>>>> 3. Providing guidance on how to achieve this pattern within the >>>> same >>>> >>>>>>> IdP >>>> >>>>>>> >>>> >>>>>>> RFC 8693 (Token Exchange) doesn't fully address this use case >>>> as it >>>> >>>>>>> requires sending the actual token (subject_token), which is what >>>> >>>>>>> we're >>>> >>>>>>> trying to avoid. >>>> >>>>>>> >>>> >>>>>>> Security Considerations: >>>> >>>>>>> >>>> >>>>>>> With zero-trust validation, same-IdP assertions can be just as >>>> secure >>>> >>>>>>> as cross-IdP: >>>> >>>>>>> - Validate assertion issuer is authorized >>>> >>>>>>> - Apply fresh authorization policy evaluation >>>> >>>>>>> - Enforce audience restrictions >>>> >>>>>>> - Use short-lived assertions >>>> >>>>>>> - Implement scope intersection, not broadening >>>> >>>>>>> >>>> >>>>>>> Would appreciate the working group's consideration of this use >>>> case. >>>> >>>>>>> >>>> >>>>>>> Best regards, >>>> >>>>>>> Tarun Nanduri. >>>> >>>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>> OAuth mailing list -- [email protected] >>>> >>>> To unsubscribe send an email to [email protected] >>>> >>>> >>>> >>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> >>> privileged material for the sole use of the intended recipient(s). >>>> Any >>>> >>> review, use, distribution or disclosure by others is strictly >>>> prohibited. >>>> >>> If you have received this communication in error, please notify the >>>> sender >>>> >>> immediately by e-mail and delete the message and any file >>>> attachments from >>>> >>> your computer. Thank you.* >>>> >>> _______________________________________________ >>>> >>> OAuth mailing list -- [email protected] >>>> >>> To unsubscribe send an email to [email protected] >>>> >>> >>>> >> >>>> -------------- next part -------------- >>>> A message part incompatible with plain text digests has been removed ... >>>> Name: not available >>>> Type: text/html >>>> Size: 16713 bytes >>>> Desc: not available >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>> >>>> ------------------------------ >>>> >>>> End of OAuth Digest, Vol 208, Issue 19 >>>> ************************************** >>>> >>> >>> >>> -- >>> Chris Keogh >>> _______________________________________________ >>> OAuth mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> > > -- > Chris Keogh > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
