Web Authorization Protocol Y. Zehavi Internet-Draft Raiffeisen Bank International Intended status: Standards Track 25 June 2025 Expires: 27 December 2025 OAuth 2.0 App2App Browserless Flow draft-zehavi-oauth-app2app-browserless-03 Abstract This document describes a protocol connecting 2 native apps via the OAuth [App2App] pattern, to achieve native user navigation (no web browser required), regardless of any number of OAuth brokers federating the request across trust domains. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://yaron- zehavi.github.io/oauth-app2app-browserless/draft-zehavi-oauth- app2app-browserless.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zehavi-oauth- app2app-browserless/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/yaron-zehavi/oauth-app2app-browserless. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Zehavi Expires 27 December 2025 [Page 1] Internet-Draft Native OAuth App2App June 2025 This Internet-Draft will expire on 27 December 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Difference from OpenID.Native-SSO . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Challenge of App2App with OAuth Brokers . . . . . . . . . . . 5 3.1. App2App with OAuth Brokers requires a web browser . . . . 5 3.2. Impact of using a web browser . . . . . . . . . . . . . . 5 4. App2Web with brokers . . . . . . . . . . . . . . . . . . . . 6 5. Browser-less App2App with OAuth Brokers . . . . . . . . . . . 7 5.1. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 7 5.2. New Parameters and Values . . . . . . . . . . . . . . . . 8 5.3. Validation of native_callback_uri . . . . . . . . . . . . 9 5.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 9 5.4.1. Client App calls Initial Authorization Server . . . . 9 5.4.2. Initial Authorization Server returns authorization request to Downstream Authorization Server . . . . . 10 5.4.3. Client App invokes app of User-Interacting Authorization Server . . . . . . . . . . . . . . . . 10 5.4.4. Processing by User-Interacting Authorization Server's App: . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4.5. Client App traverses OAuth Brokers in reverse order . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4.6. Client App obtains response . . . . . . . . . . . . . 12 6. Detecting Presence of Native Apps claiming Urls . . . . . . . 12 6.1. Android . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. OAuth request forgery and manipulation . . . . . . . . . 12 7.2. Secure Native application communication . . . . . . . . . 13 7.3. Deep link hijacking . . . . . . . . . . . . . . . . . . . 13 Zehavi Expires 27 December 2025 [Page 2] Internet-Draft Native OAuth App2App June 2025 7.4. Open redirection by Client App . . . . . . . . . . . . . 13 7.5. Open redirection by User-Interacting Authorization Server's App . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.6. Authorization code theft and injection . . . . . . . . . 13 7.7. Handling of Cookies . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document, _OAuth 2.0 App2App Browserless Flow_ (Native App2App), presents a protocol enabling native OAuth [App2App] *browser-less* navigation across apps. It addresses the challenges presented when using a web browser to navigate through *one or more* Brokering Authorization Servers: * Such _OAuth Brokers_ are required when _Client App_ is not an OAuth client of the _User-Interacting Authorization Server_ and so they federate the flow across trust domains. * Since no app owns _OAuth Brokers'_ urls, App2App flows involving brokers require a web browser, which degrades the user experience. This document specifies: * A new parameter to the authorization endpoint: *native_callback_uri*. * A new scope value: *app2app*. * A new error_description value: *native_callback_uri_not_claimed*. 1.1. Difference from OpenID.Native-SSO [OpenID.Native-SSO] also offers a native SSO flow across apps. However, it is limited to apps: * Published by the same issuer, therefore can securely share information. * Using the same Authorization Server. Zehavi Expires 27 December 2025 [Page 3] Internet-Draft Native OAuth App2App June 2025 1.2. Terminology In addition to the terms defined in referenced specifications, this document uses the following terms: "OAuth": In this document, "OAuth" refers to OAuth 2.0, [RFC6749] and [RFC6750] as well as [OpenID], both in their *authorization code flow*. "PKCE": Proof Key for Code Exchange (PKCE) [RFC7636], a mechanism to prevent various attacks on OAuth authorization codes. "OAuth Broker": A component acting as an Authorization Server for its clients, as well as an OAuth Client towards _Downstream Authorization Servers_. Brokers are used to facilitate a trust relationship when there is no direct relation between an OAuth Client and the final Authorization Server where end-user authenticates and authorizes. This pattern is in current use to establish trust in federation use cases in Academia and in the business world, across corporations. Note: It is possible OAuth Brokers will be superseded in the future by [OpenID.Federation], offering dynamic trust establishment. "Client App": A Native app implementing "OAuth 2.0 for Native Apps" [RFC8252] as an OAuth client of _Initial Authorization Server_. Client's redirect_uri is claimed by the app. "Initial Authorization Server": The Authorization Server of _Client App_ which acts as an _OAuth Broker_ as an OAuth client of a _Downstream Authorization Server_. "Downstream Authorization Server": An Authorization Server which may be an _OAuth Broker_ or a _User-Interacting Authorization Server_. "User-Interacting Authorization Server": The Authorization Server which interacts with end-user to perform authentication and authorization. "User-Interacting App": Native App of _User-Interacting Authorization Server_. "Deep Link": A url claimed by a native application. "Native Callback uri": _Client App's_ redirect_uri, claimed as a deep link. This deep link is invoked by _User-Interacting App_ to natively return to _Client App_. Zehavi Expires 27 December 2025 [Page 4] Internet-Draft Native OAuth App2App June 2025 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Challenge of App2App with OAuth Brokers 3.1. App2App with OAuth Brokers requires a web browser +------------------------------------------------------------------------------------+ | +-----------+ | | | | | | | Client | Mobile Browser | | | App | +------------------------------------------------------------------+ | | | | | | | | +-----------+ | +---------+ +--------------+ +--------------------+ | | | | | | | | Downstream | | User- | | | | +------>| Initial |------>| Authorization|------>| Authenticating | | | | Authorization| | Broker | Auth. | Servers | Auth. | Authorization | | | | Request | +---------+ Req. +--------------+ Req. | Server | | | | | +---------+----------+ | | | +----------------------------------------------------|-------------+ | | +--------------+ | | | | User- | | | | |Authenticating|<--------------------------------------------------+ | | | App | Deep Link | | +--------------+ | +------------------------------------------------------------------------------------+ Mobile Device Figure 1: App2App with brokers and browser (redirects back to Client not depicted) Since no native app claims _OAuth Brokers'_ urls, OAuth requests and redirect_uri responses to and from _OAuth Brokers_ are handled by a web browser as the User Agent. 3.2. Impact of using a web browser Using a web browser may degrade the user experience in several ways: * Some browser's support for deep links is limited by design, or by the settings used. Zehavi Expires 27 December 2025 [Page 5] Internet-Draft Native OAuth App2App June 2025 * The browser may prompt end-user for consent before opening deep links, introducing additional friction. * Browser's loading of urls and redirecting may be noticeable by end-user, rendering the UX less smooth. * App developers cannot control which browser will handle the response redirect_uri. This poses a risk that necessary cookies used to bind session identifiers to the user agent (nonce, state or PKCE verifier) will be unavailable, which may break the flow. * After the flow is complete, "orphan" browser tabs might remain. While they do not directly impact the flow, they can be regarded as unnecessary "clutter". 4. App2Web with brokers +------------------------------------------------------------------------------------+ | +-----------+ | | | | | | | Client | Mobile Browser | | | App | +------------------------------------------------------------------+ | | | | | | | | +-----------+ | +---------+ +--------------+ +--------------------+ | | | | | | | | Downstream | | User- | | | | +------>| Initial |------>| Authorization|------>| Authenticating | | | | Authorization| | Broker | Auth. | Servers | Auth. | Authorization | | | | Request | +---------+ Req. +--------------+ Req. | Server | | | | | +-+----------------+-+ | | | | | User- | | | | | | Authenticating | | | | | | Web UI | | | | | +----------------+ | | | +------------------------------------------------------------------+ | +------------------------------------------------------------------------------------+ Mobile Device Figure 2: App2Web with brokers (redirects back to Client not depicted) End-user's device may not have an app claiming _User-Interacting Authorization Server's_ urls, when: * _User-Interacting Authorization Server_ offers no native app. * Or such an app is offered, but is not installed on the end-user's device. Zehavi Expires 27 December 2025 [Page 6] Internet-Draft Native OAuth App2App June 2025 In such case interacting with _User-Interacting Authorization Server's_ MUST use the browser as user agent. This is similar to the flow described in "OAuth 2.0 for Native Apps" [RFC8252], and referred to in [App2App] as *App2Web*, and is therefore not discussed further in this document. 5. Browser-less App2App with OAuth Brokers 5.1. Flow Diagram +--------------------------------------------------+ | (8) +---------------+ | | +---------------->| Initial | | | | | Authorization | | | +--------------+ (1) | Server | | | | Client |------------->| | | | | App |<-------------| (OAuth Broker)| | | | | (2) +---------------+ | | +--------------+ | | ^ | ^ ^ | | | | | | (3) +---------------+ | | | | | +---------------->| | | | | | +------------------>| Downstream | | | | | (7) | Authorization | | | | | | Servers | | | | | | | | |(6)| |(4) +---------------+ | | | v | | +----------------+ +---------------+ | | | | | User- | | | | User- |<---------->| Authenticating| | | | Authenticating | (5) | Authorization | | | | App | | Server | | | +----------------+ +---------------+ | +--------------------------------------------------+ Mobile Device Figure 3: Browser-less App2App with Brokers * (1) _Client App_ presents an authorization request to _Initial Authorization Server_, indicating app2app flow using new scope value *app2app*. * (2) _Initial Authorization Server_ returns an authorization request for Downstream Authorization Server, including Client App's redirect_uri as *native_callback_uri*. Zehavi Expires 27 December 2025 [Page 7] Internet-Draft Native OAuth App2App June 2025 * (3) _Client App_ checks if the returned authorization request url is claimed by an app on the device and if so proceeds to the next step. Otherwise it loops through Downstream Authorization Servers, calling their authorization endpoints and processing their HTTP 3xx redirect responses, until a url claimed by an app on the device is reached. * (4) _Client App_ natively invokes _User-Interacting App_. * (5) _User-Interacting App_ authenticates user and authorizes the request. * (6) _User-Interacting App_ natively invokes *native_callback_uri* (overriding the request's redirect_uri), providing as a parameter the redirect_uri with its response parameters. * (7) _Client App_ loops through Authorization Servers in reverse order, starting from the redirect_uri it received from the _User- Interacting App_. It calls the first redirect_uri and any subsequent uri obtained as 3xx redirect directive, until it obtains a location header indicating its own redirect_uri. * (8) _Client App_ exchanges code for tokens and the flow is complete. 5.2. New Parameters and Values The protocol described in this document requires _User-Interacting App_ to natively navigate end-user back to Client App, for which it requires Client App's native_callback_uri. Therefore this document defines new parameters and values. "*app2app*": New scope value, used by _Client App_ to request an app2app flow from _Initial Authorization Server_. _Initial Authorization Server_, processing an app2app flow according to this document, MUST provide Client App's redirect_uri as Native Callback uri to _Downstream Authorization Server_ using one of the following options: "*native_callback_uri*": OPTIONAL. New authorization endpoint request parameter. When *native_callback_uri* is provided, structured scope *app2app:native_callback_uri* MUST NOT be provided. "*app2app:{_native_callback_uri_}*": OPTIONAL. New structured scope Zehavi Expires 27 December 2025 [Page 8] Internet-Draft Native OAuth App2App June 2025 value including the *app2app* flag as well as the Client's *native_callback_uri*, separated by a colon. When structured scope *app2app:{_native_callback_uri_}* is provided, *native_callback_uri* MUST NOT be provided. *native_callback_uri* accepts the following query parameter when invoked by _User-Interacting Authorization Server's App_: "*redirect_uri*": url-encoded OAuth redirect_uri with its response parameters. _Downstream Authorization Server_, processing an app2app flow according to this document: * MUST retain the *native_callback_uri* in downstream authorization requests created. * MAY validate *native_callback_uri*. 5.3. Validation of native_callback_uri Validation of *native_callback_uri* by _User-Interacting Authorization Server_ and its App is RECOMMENDED, to mitiagte open redirection attacks. A validating Authorization Server MAY use various mechanisms outside the scope of this document. For example, validation using [OpenID.Federation] is possible: * Strip url path from *native_callback_uri* (retaining the DNS domain). * Add the url path /.well-known/openid-federation and perform trust chain resolution. * Inspect Client's metadata for redirect_uri's and validate *native_callback_uri* is included. 5.4. Protocol Flow 5.4.1. Client App calls Initial Authorization Server Client App calls Initial Authorization Server's authorization_endpoint to initiate an authorization code flow and indicates App2App flow using the scope: *app2app*. Zehavi Expires 27 December 2025 [Page 9] Internet-Draft Native OAuth App2App June 2025 5.4.2. Initial Authorization Server returns authorization request to Downstream Authorization Server _Initial Authorization Server_ SHALL process Client's request and return an HTTP 3xx response with a Location header containing an authorization request url towards _Downstream Authorization Server's_ authorization_endpoint. The request SHALL include Client's redirect_uri as *native_callback_uri* in one of the methods specified in this document. 5.4.3. Client App invokes app of User-Interacting Authorization Server Client App SHALL use OS mechanisms to locate an app installed on the device claiming the authorization request url. If so, _Client App_ SHALL natively invoke the app claiming the url to process the authorization request. This achieves native navigation across applications. If an app handling the authorization request url is not found, _Client App_ SHALL use HTTP to call the authorization request url and process the response: * If the response is successful (HTTP Code 2xx), it is assumed to be the User-Interacting Authorization Server. This means the _Client App_ "over-stepped" and MUST downgrade to App2Web. * If the response is a redirect instruction (HTTP Code 3xx + Location header), _Client App_ SHALL repeat the logic previously described: - Check if an app owns the obtained url, and if so natively invoke it. - Otherwise use HTTP to call the obtained url and analyze the response. * Handle error response (HTTP 4xx / 5xx) for example by displaying the error. As the _Client App_ traverses through Brokers, it SHALL maintain a list of all the DNS domains it traverses, which serves later as the Allowlist when traversing the response. Zehavi Expires 27 December 2025 [Page 10] Internet-Draft Native OAuth App2App June 2025 5.4.3.1. Downgrade to App2Web If _Client App_ reaches a _User-Interacting Authorization Server_ but failed to locate an app claiming its urls, it may be impossible to relaunch the last authorization request on the browser as it might have included a single-use "OAuth 2.0 Pushed Authorization Requests" [RFC9126] request_uri which by now has been used and is therefore invalid. In such a case the _Client App_ MUST start over, generating a new authorization request without the *app2app* scope, which is then launched on the browser. The remaining flow follows "OAuth 2.0 for Native Apps" [RFC8252] and is therefore not elaborated further in this document. 5.4.4. Processing by User-Interacting Authorization Server's App: The _User-Interacting Authorization Server_ SHALL handle the authorization request using its native app: * Authenticates end-user and authorizes the request. * SHALL use *native_callback_uri* to override the request's original redirect_uri: - _User-Interacting Authorization Server's app_ validates that an app claiming *native_callback_uri* is on the device - If so it natively invokes *native_callback_uri* with the redirect url and its response parameters as the url-encoded query parameter *redirect_uri*. - If such an app does not exist on the device, the flow terminates and _User-Interacting Authorization Server's app_ redirects to redirect_uri with: o error=invalid_request. o error_description=*native_callback_uri_not_claimed*. 5.4.5. Client App traverses OAuth Brokers in reverse order _Client App_ is natively invoked by _User-Interacting Authorization Server App_, with the request's redirect_uri. Zehavi Expires 27 December 2025 [Page 11] Internet-Draft Native OAuth App2App June 2025 _Client App_ MUST validate this url, and any url subsequently obtained via a 3xx redirect instruction, against the Allowlist it previously generated, and MUST fail if any url is not included in the Allowlist. _Client App_ SHALL invoke the url it received using HTTP GET: * If the response is a redirect instruction (HTTP Code 3xx + Location header), _Client App_ SHALL repeat the logic and proceed to call obtained urls until reaching its own redirect_uri (*native_callback_uri*). * SHALL handle any other HTTP code (2xx / 4xx / 5xx) as a failure. 5.4.6. Client App obtains response Once _Client App's_ own redirect_uri is returned in a redirect 3xx directive, the traversal of OAuth Brokers is complete. _Client App_ SHALL proceed according to OAuth to exchange code for tokens, or handle error responses. 6. Detecting Presence of Native Apps claiming Urls Native Apps on iOS and Android MAY use OS SDK's to detect if an app owns a url. The general method is the same - App calls an SDK to open the url as deep link and handles an exception thrown if no matching app is found. 6.1. Android App SHALL invoke Android [android.method.intent] method with FLAG_ACTIVITY_REQUIRE_NON_BROWSER, which throws ActivityNotFoundException if no matching app is found. 6.2. iOS App SHALL invoke iOS [iOS.method.openUrl] method with options [iOS.option.universalLinksOnly] which ensures URLs must be universal links and have an app configured to open them. Otherwise the method returns false in completion.success 7. Security Considerations 7.1. OAuth request forgery and manipulation It is RECOMMENDED that _Client App_ acts as a confidential OAuth client. Zehavi Expires 27 December 2025 [Page 12] Internet-Draft Native OAuth App2App June 2025 7.2. Secure Native application communication If _Client App_ uses a Backend it is RECOMMENDED to communicate with it securely: * Use TLS in up to date versions and ciphers. * Use DNSSEC. * Perform certificate pinning. 7.3. Deep link hijacking It is RECOMMENDED that all apps in this specification shall use https-scheme deep links (Android App Links / iOS universal links). Apps SHOULD implement the most specific package identifiers mitigating deep link hijacking by malicious apps. 7.4. Open redirection by Client App Client App SHALL construct an Allowlist of DNS domains it traverses while processing the request, used to enforce all urls it later traverses during response processing. This mitigates open redirection attacks as urls not in this Allowlist SHALL be rejected. In addition _Client App_ MUST ignore any invocation for response processing which is not in the context of a request it initiated. It is RECOMMENDED the Allowlist be managed as a single-use object, destructed after each protocol flow ends. It is RECOMMENDED _Client App_ allows only one OAuth request processing at a time. 7.5. Open redirection by User-Interacting Authorization Server's App It is RECOMMENDED that User-Interacting Authorization Server's App establishes trust in *native_callback_uri* to mitigate open redirection attacks and reject untrusted urls. 7.6. Authorization code theft and injection It is RECOMMENDED that PKCE is used and that the code_verifier is tied to the _Client App_ instance. Zehavi Expires 27 December 2025 [Page 13] Internet-Draft Native OAuth App2App June 2025 7.7. Handling of Cookies It can be assumed that Authorization Servers will use Cookies to bind security elements (state, nonce, PKCE) to the user agent, which will break the flow if these cookies are not present in subsequent HTTP requests. Therefore, _Client App_ MUST handle Cookies: * Store cookies it obtains on HTTP responses. * Send cookies on subsequent HTTP requests to Authorization Servers that returned such cookies. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [OpenID] Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [OpenID.Federation] Hedberg, Ed, R., Jones, M. B., Solberg, A. A., Bradley, J., De Marco, G., and V. Dzhuvinov, "OpenID Federation 1.0", March 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . Zehavi Expires 27 December 2025 [Page 14] Internet-Draft Native OAuth App2App June 2025 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . 9.2. Informative References [android.method.intent] "Android Intent Method", n.d., . [App2App] Heenan, J., "Guest Blog: Implementing App-to-App Authorisation in OAuth2/OpenID Connect", October 2019, . [iOS.method.openUrl] "iOS open(_:options:completionHandler:) Method", n.d., . [iOS.option.universalLinksOnly] "iOS method property universalLinksOnly", n.d., . [OpenID.Native-SSO] Fletcher, G., "OpenID Connect Native SSO for Mobile Apps", November 2022, . Zehavi Expires 27 December 2025 [Page 15] Internet-Draft Native OAuth App2App June 2025 Acknowledgments The authors would like to thank the following individuals who contributed ideas, feedback, and wording that shaped and formed the final specification: Henrik Kroll, Grese Hyseni. As well as the attendees of the OAuth Security Workshop 2025 session in which this topic was discussed for their ideas and feedback. Author's Address Yaron Zehavi Raiffeisen Bank International Email: yaron.zehavi@rbinternational.com Zehavi Expires 27 December 2025 [Page 16]