Hi Yaron,Here is my review of draft-zehavi-oauth-app2app-browserless-07.In general, I want to mention ahead that I have little experience in this problem space and also not much knowledge in the prior art and related documents. However, I am aware of the UX problem as an end user.General comments: Do you see this document scoped to only tightly couple enterprise environments where authorization servers are mutually trusted or also in open ecosystems where trust may not be mutual or not prior established?In the case of an open ecosystem I'm curious if public IDPs would consider implementing this, knowing that they lose a significant amount of control over the flow, prompts, display decisions and more, they can make.In the case of closed ecosystems I wonder if the dynamic nature of this draft isn't overkill and a lot of this cannot be logic within the app.I'm also curious to know if you've considered making a preflight request to the traditional authorized endpoint and act based on the response. On redirect use mapping to invoke native, if not open browser.On specific sections: 3.1
- The flow descriptions don't match the figure. E.g. "User-Interacting App authenticates end-user" (I believe it should be "User-Authenticating App"). I also noticed this throughout the document. 3.5.3 - I believe there's a trust problem when any arbitrary authentication can prompt the user for input within the native app. This creates the perception that the choice is given by the native app and not by a third party. TLDR: the authorization server trusts the client to prompt the user according to the given information and properly forward the choice back to the AS. I believe this is quite significant. - - Another angle to look at this is comparing it with FPA. Here there's strong trust between client & authorization servers. I believe this draft has the same with the differentiation that 1 app has strong trust with each authorization server in the chain except the last, which has its own app I assume? Or do I understand this wrong and it's expected that an app only prompts the choice of its own Authorization server? If yes, is this "Federated First Party App" only? 3.6 - The native_callback_uri should be an allowed redirectURI of the client IMO. Otherwise you get into the same security problems as in browser based flows. 3.7 - Do you see security considerations when intermediaries are skipped on redirects? I can imagine that the obtained chain must be traversed back via redirects in the exact reversed order. - What is your opinion on post-authentication prompts such as consent, warnings, etc.? Those can be pretty dynamic. Do these situations require a complete abortion of the flow and repeating on the browser? 5.2 - It is mentioned that trust establishment in native_callback_uri is RECOMMENDED by User-Interacting App. Which makes me wonder even more if the native_callback_uri cannot be just a matter of configuration? 5.5 - I wonder why PKCE is only recommended and not required. This seems like an important security consideration. Kind regards, Arndt On Thu, Oct 16, 2025 at 7:20 PM Yaron ZEHAVI < [email protected]> wrote: > Dears, > > With a view to IETF 124 in 2 weeks I’d like to reach out and ask for your > feedback on this draft, which was presented in IETF 123: > > https://datatracker.ietf.org/doc/draft-zehavi-oauth-app2app-browserless/ > > > > Regards, > > Yaron ZEHAVI > 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 > _______________________________________________ > 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]
