Good morning. We have reached the stage where we feel we have received sufficient technical feedback on the solutions proposed here that we are able to close this RFC and shift our focus to implementation. We’re grateful for the responses received and appreciate the engagement we have had from our partner community.
This has been an extraordinarily protracted process - our original RFC-14 was the first to ask for community feedback on the work we are doing to bring admins more control when it comes to apps in cloud.
One such initiative is a new control for org admins to block cloud app access to certain Jira projects or Confluence spaces. We believe this will help address concerns around “all-or-nothing” app access, and generally improve app migrations and app adoption amongst our more privacy-sensitive customers in cloud.
It is inevitable that Atlassian’s creating new controls for org admins to control app access to content will result in some changes to the way apps work - our intention is to provide sufficient APIs that apps can make these changes in a forward-compatible way, noting that seeing increasing regulatory controls and compliance requirements from our bigger Enterprise customers means the need for org admin controls of cloud apps will only increase.
RFC-25 was our first attempt to provide solutions to address the feedback we had received - and this elicited feedback that that was sufficient to send us back to the drawing board to consider different approaches. And then RFC-29 is our subsequent description of the APIs we propose to enable apps to function well in an environment where they may be blocked by org admins from particular sets of content.
During the RFC process we heard a variety of concerns from the community - again thank you for sharing these with us:
- Concerns about the ability of apps to subscribe to notification events and iterate through large quantities of data within messaging processing time constraints. This led to a substantial reworking of the event publishing mechanism.
- Concerns about the use of ARIs. We reworked our APIs to use product-native identifiers instead of ARIs.
- Concerns about the use of GraphQL as an API protocol. We moved back to providing new endpoints within RESTful product APIs.
- Concerns about the use of industry standard specifications which partners had not heard of and did not themselves need. We are confident that partners not interested in this specification will be able to ignore it and subscribe to events as they always have, while other event consumers will be able to benefit from the adoption of an industry-wide specification for defining event metadata.
- Mistakes in API contracts, such as incorrect data types for product identifiers. Thank you for pointing these out.
- Missing API capabilities such as events when org admins block an app from a Project or Space. Thank you for your use cases explaining why these are necessary.
- Concerns about the use of out-of-band mechanisms such as separate APIs instead of modifying Jira and Confluence APIs to notify apps (whether by header or response code/body) when App Access Rules had affected the response they had received. While modification of API responses was the first solution we investigated, it became clear to us that any Atlassian-wide program to deliver this would likely take years to deliver and our mutual customers need those controls now.
We will continue to iterate on the APIs we have detailed in this RFC to improve them - and as mentioned we expect future increases in org admin controls over how and where cloud apps operate. Adopting these APIs will position apps well for the future.
We will soon be launching an app access rule EAP. Those of you who join the EAP will be able to create data security polices on a nominated site and learn more about how this feature affects your end users’ experience. We will continue to work with you to understand how you make use of the scoped API changes and events and address any additional concerns you may have.
Best regards