RFC-94: Configurable Egress and Remotes

[PetarPetrovAppfire]

To second @PaoloCampanelli’s comment - now that you have proposed RFC-97 REST APIs in Forge, you will have to make a decision regarding RoA and configurable egress.

There is effectively no difference between the two in terms of control and visibility - an app can egress arbitrary data through either mechanism, and in both cases, it’s the product user who approves the egress and configures authentication between the app and the external system. Whether the egress is initiated internally or externally is an irrelevant detail.

[billjamison]

Digging into this farther, it appears that the list of set remotes and domains is not available when there is no user present, such as in the context of a scheduled trigger. If an app requires access to this information, it must separately store this configuration. What’s driving this? It requires duplicate storage and different patterns in different places, neither of which is desirable.

[HarinathReddyAppfire]

Having the configurable egress feature can unblock many formatting apps to be ROA like markdown, html, reporting. These apps can fetch resources like scripts, images, css from different CDN’s which are customer usage specific.

[remie]

@HarinathReddyAppfire, in the current proposal, configurable egress will not be considered for ROA:

@SeanBourke

Marketplace signals and program eligibility

Configurable egress / remotes enable partners to deliver more flexible apps which increase customer trust by enabling them to better understand and control how their data is managed. With that said, the ability to share data remotely would preclude these apps from being eligible for Runs on Atlassian in the program’s current definition and state.

This RFC will not explore the impacts of the utilisation of this capability on RoA or other marketplace signals at this time.

[SeanBourke]

@billjamison

Digging into this farther, it appears that the list of set remotes and domains is not available when there is no user present, such as in the context of a scheduled trigger.

Thanks for the feedback and good catch; it’s important that backend functions also have awareness of when/where/what permissions have been established, so that they can act accordingly (particularly if a feature if gated by egress being enabled). A lot of the focus of this RFC was on front-end enablement. I’ll take this away for further exploration with the team.

[SeanBourke]

Hey @remie,

That is not correct - the initial RFC noted that it would not be eligible under the current definition and given other research which is on-going to assess how configurable egress and REST APIs align to Runs on Atlassian, I preferenced to not include it in scope for discussion, so we could focus on use cases and the technical/approval implementation.

In later responses, we have clarified that this is still under exploration and that feedback is being considered.

@SeanBourke

This is still being explored - as noted, we are assessing the implication of this to other marketplace badges (such as Runs on Atlassian).

@SeanBourke

To everyone who has responded regarding Runs on Atlassian, we appreciate your feedback. We are continuing to discuss the implications of configurable remotes/egress against our marketplace programs and your inputs and feedback supports these conversations.

As noted in the original post, it is unlikely we’ll share a distinct position as part of this RFC, however we will share more details once they are available.

[remie]

@SeanBourke, can you elaborate more on the timeframe? Because I would expect based on these quotes that the implementation of this RFC will be shipped without a distinct position.

In my interpretation, this means that the initial release of configurable egress will not be RoA compliant. Is that incorrect?