[OAUTH-WG] Re: OAuth Digest, Vol 208, Issue 19

[Atul Tulshibagwale <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]>
>> 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, <[e-mail]> wrote:
>>>
>>>> Send OAuth mailing list submissions to
>>>>         [e-mail]
>>>>
>>>> To subscribe or unsubscribe via email, send a message with subject or
>>>> body 'help' to
>>>>         [e-mail]
>>>>
>>>> You can reach the person managing the list at
>>>>         [e-mail]
>>>>
>>>> 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 <[e-mail]>
>>>> Subject: [OAUTH-WG] Re: Feedback on ID-JAG same IdP prohibition -
>>>>         Application to Application Delegation
>>>> To: Tarun Nanduri <[e-mail]>
>>>> Cc: Brian Campbell <bcampbell=[e-mail]>,
>>>>         [e-mail]
>>>> Message-ID:
>>>>         <
>>>> [e-mail]>
>>>> 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 <[e-mail]>
>>>> 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
>>>> <[e-mail]>
>>>> > 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=
>>>> >> [e-mail]> 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 <
>>>> [e-mail]>
>>>> >>> 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 <
>>>> [e-mail]>
>>>> >>>> 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 <[e-mail]>
>>>> >>>>> 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 <
>>>> [e-mail]>
>>>> >>>>>> 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 -- [e-mail]
>>>> >>>> To unsubscribe send an email to [e-mail]
>>>> >>>>
>>>> >>>
>>>> >>> *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 -- [e-mail]
>>>> >>> To unsubscribe send an email to [e-mail]
>>>> >>>
>>>> >>
>>>> -------------- 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of OAuth Digest, Vol 208, Issue 19
>>>> **************************************
>>>>
>>>
>>>
>>> --
>>> Chris Keogh
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>
> --
> Chris Keogh
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>