Dear Arndt, Thank you for taking the time to provide this valuable feedback, I appreciate it.
Enterprise vs open ecosystems – The use-case that initiated this work stems from an enterprise environment, but we’re avoiding making custom trust assumptions, rather leverage standard mechanisms for trust establishment (e.g jwks endpoints). One exception to this is the user-interacting app trusting the native_callback_uri for which we're considering app configuration of allowed urls. However, by using OpenID Federation, I believe the spec fits open ecosystems as well, with dynamic trust establishment. It's too soon to tell of course how things will evolve, but since it’s possible we wanted to keep the standard as interoperable and general as possible. Will public IDPs provide it? I suppose they will follow if their peers offer an enhanced user experience using the standard. As for the dynamic nature - I don't think a preflight call would simplify matters as by definition we’re discussing a federation scenario, where the client has a direct relationship with its AS only, so pre-flighting requires calling the entire federation chain, which to seems equivalent effort as following the prescribed flow. Feedback for specific sections: 3.1 - Fixed the drawing, thanks for noticing! 3.5.3 - This is about the routing response, used when a downstream AS, which doesn't authenticate user but requires additional information to guide routing, e.g: customer segment (retail / corporate) or email (to identify user's org): * In terms of informing the user who is asking, the requesting AS can provide a logo shown to user as the audience of the information. It's true that a native app controls the UI and therefore has access to the information. Therefore the security considerations say this must not be used for sensitive information. * I agree with the Federated FPA analogy. To your question, the client has a trust relationship only with its authorization server. However, each subsequent party has a trust relationship with the next downstream party, similar as with web redirect federation flows. 3.6 - I agree, added this requirement. Thanks! 3.7: * Indeed, the call chain must be traversed back in the reverse order. Skipping an intermediary is equivalent to an OAuth authorization code falling in the wrong hands, which should be mitigated by mechanisms like PKCE. * Authentication is performed by the user-interacting app whose responsible for all required user interactions, not just authentication. This app should perform also prompts, consent, etc before redirecting back to client app 5.2 - Indeed, in a closed ecosystem such as a multi-subsidiary enterprise as the company I work for, app configuration of allowlist is how we're planning to establish this trust. In open ecosystems it could be achieved by other means, such as OpenID Federation. 5.5 - Very good point. I think PKCE should definitely be used, and that the code_verifier of intermediate authorization servers needs to be bound to the user agent. This issue was also raised by George Fletcher: https://github.com/yaron-zehavi/oauth-app2app-browserless/issues/18 and following his feedback we re-instated into the draft that Client App is required to support cookies. I'm just not sure what's the accepted convention when writing rfc's, regarding how mandatory to make security requirements, or rather to favor interoperability with other rfc's. So far I've seen rfc's mandating less on security requirements, and this work being done in profiles like FAPI. But happy for guidance here on what is the right balance. I’ll raise this point in the upcoming meeting. Once again, thanks for your valuable feedback. Regards, Yaron Zehavi Classification: GENERAL From: Arndt Schwenkschuster <[email protected]> Sent: Friday, October 17, 2025 12:56 PM To: Yaron ZEHAVI <[email protected]> Cc: [email protected] Subject: Re: [OAUTH-WG] Requesting feedback on app2app browser-less draft You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> This message is from an external sender - be cautious, particularly with links and attachments. 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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
