App Access to Data - What we've learned

[AbigailLee]

Hello developers,

Remember granular scopes? Me neither. Because this time we are redesigning the approach to scopes

We spoke to 10 partners about their expectations and preferences regarding scope selection for 3LO and Forge applications. We learned about their pain points from the previous granular scopes rollout and what their ideal scenario would be with the new scopes.

Below is a summary of what we learned about scope preferences and how we could make a better migration process. We also spoke to customers about their expectations of giving data to online apps and to see if they understand the consent process. The team is still working on ideating the best solutions for partners and customers but wanted to show an initial report of what we have found so far.

What was the feedback?

We gave partners different tasks to conduct using proposed concepts and asked for feedback. The two proposed concepts were a simple list of scopes approach and a resource-first approach (smaller number of scopes shared across endpoints or one scope per endpoint, leading to a larger number of scopes).

Simple list of scopes

Resource-first approach

Selecting the new scopes

There’s a variety of preferences when it comes to scope selection → it was split between both concepts

There’s a tradeoff between developer ease and flexibility in changing scopes. Strengths of the simple list of scopes are flexibility in changing scopes, reducing the risk of customer re-consent, and a smaller number of scopes to manage. Strengths of the resource-first approach are that it’s more manageable over time (ex: if an endpoint is later changed, the impact is clear due to the 1:1 scope to API relationship instead of determing which endpoints are impacted from a broader range of scopes) and it’s easier to explain to customers.

Because of the split, the Atlassian team is exploring a hybrid approach with broader scopes for less-sensitive information and granular scopes for more sensitive information. For example, a scope regarding project avatar would be less sensitive and could be incorporated into a broader scope, while a delete scope would be more granular.

Migration process

We know the migration process of the last granular scopes rollout was not ideal. Through partner feedback, we highlighted the top points that need to be addressed in the new scope migration:

• Partners want clarity on how the old scopes are mapped to new scopes
• Partners want more assistance and recommendations from Atlassian in the migration process
• Partners want a clear deprecation timeline
• Partners care about their customer experience and want to make sure there is enough advance notice the scope change and a possible re-consent is coming

We hope this gives more insight into how your feedback allows us to improve our products and services.

If you’re kicking yourself for missing an opportunity to be part of the research, send me a message and we’ll put you on a list for any future studies.

Thanks and happy holidays!
Abby from the Research and Service Experience team

[remie]

@AbigailLee

Because of the split, the Atlassian team is exploring a hybrid approach with broader scopes for less-sensitive information and granular scopes for more sensitive information. For example, a scope regarding project avatar would be less sensitive and could be incorporated into a broader scope, while a delete scope would be more granular.

Have you also considered the option of doing both? As in, keep the granular scopes and create “grouped” scopes that encompass a range of granular scopes.

Granular scopes
read:comment:jira, read:project:jira, read:user:jira

Resource scope for get comments
read:issue-comment:jira, which is a group of the granular scopes

The user will continue to give access to the granular scopes, whilst the developer can have a more manageable experience. It provides more flexibility as it will be easier to change resource scope groups. Upon changes to the resource scope groups, the user would only have to re-consent to the changed granular scopes, you will not have to ask again for scopes that the user already agreed to.

[dmitry.astapkovich]

Just a quick question: have your researched how it’s done on other platforms as well? Like Google Workspace, Monday.com, GitHub etc.?

[JuliaDaehne]

Hi @remie yes we looked into this option as well. One of the reasons we did not pursue it was the concern that customers would act more on the grouped scope without consciously reviewing the underlying scopes. In addition, an app should only request scopes that are required to perform its intended functionality. Adopting scope groups instead of single scopes did not seem the right approach.

When it comes to consent we would indeed follow what you are proposing: customers should only ever need to consent to new scopes. This should especially apply during the migration process where the move from classic to new scopes as the new scopes remain more granular and would therefore be covered by previously obtained classic scope consent.

[JuliaDaehne]

Hi @dmitry.astapkovich yes I can assure you that we thoroughly reviewed other actors in the market as well to ensure we are on top of best practice

[BenRomberg]

Our biggest app (thousands of installs) uses all possible classic Jira scopes. We have received about 1 request per thousand customers asking about those - why do we need delete access, for example.

What is much more interesting to customers is why we have access to all of their issues, I’d guess it’s around 10 requests per thousand customers. We have to answer security questionnaires and go through security audits because we suddenly have read access to all of their data.

How will the new scopes fix this? As far as I can tell, even with more granular scopes, if we request read:issue:jira we’ll again have access to all customer issues (combined maybe with user impersonation) and they will again have trouble understanding how they can limit app access to their issue data. I feel that all the other scopes combined are not as important as read access to issue data.

[remie]

@JuliaDaehne

One of the reasons we did not pursue it was the concern that customers would act more on the grouped scope without consciously reviewing the underlying scopes.

This sounds more like an assumption and less like something that has been researched? Also, maybe I did not explain myself correctly:

The customer would never see the scope group. They would only see the individual granular scopes. The grouped scopes are for developer convenience only, basically allowing developers to say “I want scope X, Y and Z”, but instead of naming them individually can say “GroupXYZ”.

@JuliaDaehne

In addition, an app should only request scopes that are required to perform its intended functionality. Adopting scope groups instead of single scopes did not seem the right approach.

I’m not following this logic. If I need read access to a comment, I will still ask for all the scopes required to access the comment. I will not ask for more scopes than required. The only difference in my proposal that instead of having to add X, Y, and Z individually I can use alias GroupXYZ.

Adding resource groups aliases does not have any customer impact, you do not loose any granularity nor does it mean anything with regard to how much access I’m going to ask. It only means that I do not have to maintain 50+ scopes in my app.

[dmitry.astapkovich]

Is there any way you can share this info? I would love to learn more about the approaches used these days with more and more regulations in place.

[JuliaDaehne]

@remie we recognised that we went too deep with granular scopes. We will therefore not move forward with the granular scopes concept which was especially confusing for customers. We are currently looking at around 20-30 scopes per product which seems more manageable for partners and customers

[JuliaDaehne]

@dmitry.astapkovich I will check with our research colleagues whether and how we can support you here (cc @AbigailLee )

[remie]

Ok, but that still does not seem to answer my question?

Even with 20-30 scopes, you can have grouped scopes? I’m not necessarily trying to be persistent here, but it does not feel like we’re having a proper conversation about this? As in, I do not feel like Atlassian (I mention this deliberately, because I want to emphasis that I consider these types of conversations not to be between individuals, but between the entities Marketplace Partner and Atlassian, to avoid any strife) is really engaging with the partner community over all the available options on how to implement scopes.

Given the way the previous implementation went south, it might be great to be able to have this conversation upfront instead of stonewalling the conversation?